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To  the  Reader 


Introduction 


Background 


Primary 

audiences 


The  Software  Process  Framework  (SPF)  is  a  document  that  provides  information 
contained  in  the  SEI  Capability  Maturity  Model  (CMM)  for  Software  vl.l  [Paulk93a] 
in  a  format  suitable  for  process  definition  and  improvement.  The  SPF  allows  users  to 
determine  if  their  organization’s  software  process  documentation  is  consistent  with  the 
recommendations  made  by  the  CMM.  When  organizational  software  process 
documentation  is  found  to  be  inconsistent  with  the  CMM,  the  SPF  provides  the  ability 
to  make  informed  decisions  regarding  the  applicability  of  specific  CMM 
recommendations. 


Many  organizations  have  started  down  the  path  of  software  process  improvement  by 
conducting  a  software  process  assessment  and  then  responding  with  action  plans  to 
address  the  assessment  findings.  At  this  point,  many  organizations  find  themselves 
struggling  to  develop  software  processes  that  a^e  consistent  with  the  CMM.  The  SPF 
helps  to  address  part  of  this  implementation  barrier  by  answering  the  question: 

How  does  an  organization  know  if  its  software  policies,  standards,  processes, 
procedures,  training,  and  tools  are  consistent  with  the  CMM? 


The  primary  audiences  of  this  document  are: 

•  Software  engineering  process  groups  (SEPGs)  or  process  engineers:  Organizational 
units  or  personnel  responsible  for  facilitating  software  process  improvement. 

•  Software  process  improvement  groups:  Organizational  teams  responsible  for 
improving  software  processes  such  as  process  action  teams  (PATs),  quality 
improvement  teams,  or  technical  working  groups  (e.g.,  a  PAT  addressing  a  software 
process  assessment  finding). 

•  Software  quality  assurance  groups  or  process  assurance:  Organizational  groups  or 
personnel  responsible  for  auditing,  reviewing,  verifying,  or  validating  software 
processes. 

Assumption:  The  primary  audiences  of  this  document  are  assumed  to  be 

experienced  in  software  process  improvement,  experierced  using  the 
SEI  CMM,  and  familiar  with  CMM-based  appraisals  ( "oftware 
process  assessments  and  software  capability  evaluations). 


Continued  on  next  page 
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To  The  Reader,  continued 


Secondary 

audiences 


Primary  uses 


Additional  uses 


Secondaiy  audiences  of  this  document  include; 

•  Managers:  Individuals  or  groups  who  are  responsible  for  planning,  controlling,  and 
improving  software  acquisition,  development,  or  maintenance  processes  and  are 
interested  in  using  the  CMM  for  software  process  improvement. 

•  Software  process  participants:  Individuals  or  groups  responsible  for  implementing 
some  portion  of  a  software  acquisition,  development,  or  maintenance  process. 

•  Sponsors:  Personnel  responsible  for  funding,  authorizing,  and  providing  the  needed 
resources  for  software  process  improvement  efforts  that  are  based  on  the  CMM. 


The  primary  uses  of  the  SPF  are  to: 

•  Analyze  and  review  software  processes  to  check  consistency  with  the  CMM  (in  the 
context  of  process  assurance  or  process  verification). 

•  Design  software  processes  so  that  they  are  consistent  with  the  CMM. 

•  Serve  as  a  technical  reference  for  the  SEI  workshop  “Defining  Software  Processes: 
Getting  Started.” 


Additional  uses  of  the  SPF  include: 

Improvement  efforts:. 

•  Help  identify  who  should  be  involved  in  a  software  process  improvement  effort. 

•  Guide  charter  a  id  plan  development  for  process  action  teams  (PATs). 

•  Guide  PATs  in  establishing  selection  criteria  for  process  improvement  pilot  projects. 

•  Help  measure  success  criteria  for  pilot  projects  and  for  installing  and 
institutionalizing  a  software  process. 

Defining  organizational  roles: 

•  Provide  a  checklist  for  software  quality  assurance  (SQA)  reviews  and  audits. 

•  Help  define  organizational  roles,  responsibilities,  and  scope  (e.g.,  software 
configuration  management). 

Others: 

•  Provide  criteria  for  a  “good  process  definition.” 

•  Help  communicate  the  CMM  recommendations  to  achieve  a  particular  maturity  level 
to  senior  management  (or  others). 

•  Help  develop  process  guides  and  process  models  (e.g.,  SEPG  uses  the  SPF  as  a 
template  to  build  a  process  guide). 

•  Help  tailor  software  processes  (e.g.,  structure  and  content). 


Continued  on  next  page 
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To  The  Reader,  continued 


Do  not  use  for 
appraisals 


This  document  contains  a  set  of  checklists  to  help  an  organization  determine  if  its 
software  policies,  standards,  processes,  procedures,  training,  and  tools  are  consistent 
with  the  CMM. 

The  checklists  are  not  intended  to  be  scored  or  used  as  the  basis  for  an  appraisal  (i.e., 
software  capability  evaluation  or  software  process  assessment). 
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Chapter  1. 

Introduction 

• 

Overview 

Introduction 

This  chapter  will  provide  the  rationale  for  the  development  of  the  Software  Process 

Framework  (SPF).  This  chapter  also  describes  the  major  concepts  underlying  the 
development  of  the  SPF. 

In  this  chapter 

This  chapter  contains  the  following  topics; 
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About  this  Document 


Introduction 

Purpose 


Scope 

The  SPF  is 
not 


Tailoring  the 
SPF 


This  section  provides  an  overview  of  this  document, 


The  purpose  of  the  SPF  is  to  provide  guidance  for  designing,  analyzing,  and 

reviewing  software  processes  for  consistency  with  the  CMM. 

To  fulfill  its  purpose,  the  SPF: 

•  Is  based  on  the  CMM  and  the  principles  of  quality  and  process  management. 

•  Pr.  sents  information  recommended  by  the  CMM  in  a  format  suitable  for 
sof  ware  process  definition  and  improvement. 

•  ^dentifi'is  po'icie*"  standards,  processes,  procedures,  training,  and  tools 
rec  ■  .mmended  by  i- ,  CMM. 

•  Provi«,-s  .  jCf  '3  for  designing,  analyzing,  and  reviewing  software  policies, 
standards,  piocesses,  procedures,  training,  and  tools  so  that  they  can  be  consistent 
w'th  the  CMM. 


Th.  oT'  aidresses  levels  2  through  5  of  the  CMM,  version  1.1. 


T‘ '  'lofi'vare  Process  Framework  is  not: 

•  .  t  roc  d  ? .  jr  '■eaching  a  particular  maturity  level. 

The  SF  r  <  .c.-n’t  tell  you  how  to  get  to  a  particular  maturity  level,  but  rather  what 
the  “g  ’al  -Ue”  looks  like  from  a  process  definition  and  improvement 
perspective. 

•  Process  definition  training. 

The  SPF  does  not  provide  all  the  needed  knowledge  and  skills  for  defining  a 
software  process. 

•  A  method  or  process. 

The  SPF  does  not  provide  a  method  or  process  for  defining  a  software  process. 

•  A  replacement  for  the  CMM. 

The  CMM  contains  information  about  organizational  software  process  maturity; 
the  SPF  contains  similar  information  but  it  is  organized  for  the  purpose  of 
designing,  analyzing,  and  reviewing  software  processes  for  consistency  with  the 
CMM. 

•  A  process  model  or  process  guide. 


We  recommend  that  organizations  tailor  the  checklists  for  their  own  use  by 
restating  and  adding  terminology  that  is  organization  specific. 


Continued  on  next  page 
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About  this  Document,  Continued 


In  this  This  document  contains  the  following  chapters  and  appendices, 

document 


Chapter 

Title 

Description 

1 

Introduction 

Rationale  for  development  of  the 

SPF 

2 

Features  of  the  SPF 

Descriptions  and  examples  of  SPF 
feamres 

3 

How  to  use  the  SPF 

Guidance  and  examples  of  using  the 
SPF 

4 

Repeatable  Level  (Level  2) 

Checklists  of  CMM  recommended 
information  for  maturity  level  2 

5 

Defined  Level  (Level  3) 

Checklists  of  CMM  recommended 
information  for  maturity  level  3 

6 

Managed  Level  (Level  4) 

Checklists  of  CMM  recommended 
information  for  maturity  level  4 

7 

Optimizing  Level  (Level  5) 

Checklists  of  CMM  recommended 
information  for  maturity  level  5 

Appendix  A 

List  of  Acronyms 

Acronyms  used  in  the  SPF 

Appendix  B 

Glossary  of  Terms 

CMM  glossary,  with  additional  terms 
that  have  been  introduced  in  the  SPF 

Appendix  C 

Role  Translation  Table 

A  tool  to  translate  generic  CMM 
roles  into  organization  specific  roles 

Appendix  D 

General  Term  Translation 
Table 

A  tool  to  translate  generic  terms  used 
in  the  CMM  into  equivalent 
organization  terms 

Appendix  E 

References 

References  upon  which  the  SPF  is 
based 

CMU/SEI-94-HB-1 


introduction-3 


Organization  of  this  Document 


Introduction 


CMM  maturity 
levels 


Organization  of 
each  maturity 
level 


Division  of 
KPAs 


This  section  provides  an  overview  of  the  organization  of  this  document. 

Each  level  of  the  CMM  is  presented  as  a  separate  chapter  in  the  SPF.  Gray  tabs  are 
used  to  delimit  individual  maturity  levels. 

Example:  Maturity  level  2  is  presented  in  chapter  4  of  the  SPF. 


Each  maturity  level  of  the  CMM  is  presented  with  separate  sections  for  software 
policies,  standards,  processes,  and  procedures. 

Example:,  Chapter  4  contains  sections  for  the  policies,  standards,  processes,  and 
procedures  recommended  by  the  CMM  for  maturity  level  2. 


Each  section  within  a  maturity  level  (i.e.,  policies)  is  further  divided  by  key  process 
area  (KPA). 

Example:  The  policy  section  of  chapter  4  contains  a  sepaiate  entry  for  each  level 
2  KPA  (e.g.,  requirements  management  policy  information). 
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Questions  Addressed  by  the  SPF 


Introduction 


Relationship 
between  the 
SPF  and  CMM 


Questions 
facing  process 
definers 


The  SPF 
addresses  these 
questions 


This  section  presents  the  questions  facing  process  definers  that  the  SPF  has  been 
developed  to  address. 


The  CMM  contains  many  of  the  best  practices  for  developing  and  maintaining 
software.  People  defining  software  processes  consistent  with  the  CMM  require  the 
information  in  the  CMM  to  be  presented  in  a  format  that  helps  them  to  analyze 
and  structure  their  process  information. 

The  SEI  Software  Process  Definition  Project  has  developed  the  SPF  to  support  the 
definition  of  software  processes.  It  accomplishes  this  by  examining  the  CMM 
from  the  perspective  of  process  definition  and  presenting  the  results  as  a  series  of 
checklists. 


When  developing  software  process  documentation,  process  definers  are  faced  with 
three  challenging  questions: 

•  What  software  process  information  do  I  ne.ed  to  document? 

•  What  recommendations  does  the  CMM  make  about  this  process  information? 

•  How  do  I  effectively  organize  the  process  information  once  I  have  found  it? 


The  SPF  was  developed  to  address  these  questions.  In  other  words,  it  serves  as  a 
bridge  from  current  practice  to  defined  software  processes  that  are  consistent  with 
what  the  CMM  recommends. 

Each  question  facing  a  process  definer  is  addressed  by  a  different  aspect  of  the 
SPF.  The  aspects  of  the  SPF  that  address  the  questions  presented  above  are  shown 
in  the  table  below. 


This  question... 

Is  answered  by  this  aspect  of  the  SPF... 

What  software  process  information  do 

I  need  to  document? 

Process  definition  criteria 

What  does  the  CMM  say  about  this 
process  information? 

Relation  to  the  CMM 

How  do  I  organize  the  process 
information  once  I  have  found  it? 

Operational  framework 
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Process  Definition  Criteria 


Introuuction 


Deflnition: 

Process 

deflnition 

criteria 


Rationale  for 
the  criteria 


Satisfying  the 
criteria 


Process 

elements 


This  section  describes  process  definition  criteria  and  their  relationship  to  the  SPF. 


Process  definition  criteria  are  the  set  of  information  that  must  be  included  in  a 
software  process  description  for  it  to  be  usable  by  the  people  performing  the 
process. 


Determining  the  appropriate  process  definition  criteria  answers  the  question, 
“What  software  process  information  do  I  need  to  document?” 


Satisfying  the  process  definition  criteria  requires  developing  and  maintaining 
process  descriptions  that  contain  the  information  necessary  for  the  software  process 
description  to  be  usable  by  the  people  performing  the  process.  The  process 
■dpfinir-on  c'-’^pfia  can  be  satisfied  by  answering  the  basic  set  of  questions  given 


l~ach  basic  question  is  answered  by  an  associated  process  element.  The  set  of  basic 
process  questions  and  their  associated  process  elements  are  shown  in  the  table 
below. 


This  process 
element... 

Answers  this  basic  question... 

Purpose 

Why  is  a  process  performed? 

Input 

What  work  products  are  used? 

Output 

What  work  products  are  produced? 

Role 

Who  (or  what)  performs  the  activities? 

Activity 

What  is  done? 

Entry  criteria 

When  (under  what  circumstances)  can  processes  begin? 

Exit  criteria 

When  (under  what  circumstances)  can  processes  be  considered 
complete? 

Procedure 

How  are  activities  implemented? 

introduction>6 
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Process  Definition  Criteria,  Continued 


Additional 

process 

elements 


Process 
elements  and 
the  SPF 


In  addition  to  the  process  elements  shown  above,  there  are  several  other  pieces  of 
information  that  are  useftil  to  include  in  process  descriptions.  They  are: 

•  Reviews  and  audits  performed. 

•  Work  products  that  are  to  be  managed  and  controlled  (or  placed  under 
configuration  management). 

•  Measurements  to  be  made. 

•  Training. 

•  Tools. 


Every  CMM  key  process  area  is  presented  as  a  series  of  checklists  (see  Chapter  2, 
Features  of  the  SPF).  There  is  one  checklist  for  each  process  element  (except 
purpose).  For  example,  the  software  project  planning  KPA  has  checklists  for 
inputs,  outputs,  roles,  activities,  and  so  on. 

The  content  of  these  checklists  is  derived  from  the  recommendations  made  by  the 
CMM  (see  the  next  section.  Relation  to  the  CMM). 
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Relation  to  the  CMM 


Introduction 


Relation 
between  the 
CMM  and  the 
SPF 


DeHnition 


Process  element 
checklists 


This  section  describes  the  relationship  between  the  CMM  and  the  SPF. 


In  the  previous  section,  we  discussed  the  types  of  information  that  must  be 
included  in  a  software  process  description.  This  lead  to  a  set  of  basic  questions  to 
ask  regarding  a  software  process  description. 

Once  the  basic  set  of  questions  has  been  asked,  the  next  challenge  is  to  find  the 
answers.  The  CMM  is  a  normative  model  of  best  practice  from  the  software 
engineering  community  and  is  a  source  of  one  set  of  answers. 


The  recommendations  made  by  the  CMM  are  presented  as  checklists.  A  process 
element  checklist  contains  the  information  recommended  by  the  CMM  for  a 
particular  process  element. 

Example;  A  roles  checklist  describes  the  roles  recommended  by  the  CMM  for  a 
particular  key  process  area. 


Using  the  CMM  as  a  source  of  answers  to  the  basic  set  of  process  questions,  we 
developed  a  series  of  process  element  checklists  for  each  key  process  area.  These 
checklists  are  described  in  the  table  below. 


Checklist 

Description 

Roles 

List  of  roles  participating  in  process  activities 

Entry  Criteria 

Description  of  when  the  process  can  start 

Inputs 

Description  of  the  work  products  used  by  the  process 

Activities 

Description  of  the  activities  of  the  process 

Outputs 

Description  of  the  work  products  produced  by  the  process 

Exit  Criteria 

Description  of  when  the  process  is  complete 

Reviews  and 

Audits 

List  of  reviews  and  audits  performed  during  the  process 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and  controlled 

Measurements 

Description  of  process  measurements 

Documented 

Procedures 

List  of  the  activities  to  be  completed  according  to  a 
documented  procedure 

Training 

List  of  training  for  the  process 

Tools 

List  of  tools  to  support  the  process 

Introduction's 
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The  Operational  Framework 


Introduction 


Operational 
framework  and 
the  SPF 


Rationale  for 
the  operation 
framework 


This  section  describes  the  operational  framework  and  its  relation  to  the  SPF. 


The  SPF  separates  information  within  a  CMM  maturity  level  into  an  organizational 
structure  for  software  process  documentation  called  the  operational  framework. 
The  operational  fiamework  contains  the  following  process  information  types: 


Software  process  documentation  must  be  usable  for  people.  Process 
documentation  that  is  organized  poorly  will  inhibit  people  from  using  it  and 
reduce  its  effectiveness.  The  operational  framework  helps  to  eliminate  this 
problem  because  it  helps  to: 

Separate  information  into  usable  ports:  The  operational  framework  separates 
information  into  usable  parts  used  for  different  purposes.  For  example,  if  you 
want  to  see  an  organizational  policy,  detailed  training  information  included  with 
the  policy  is  irrelevant  information  (meaning  either  wasted  time  or  ignoring  the 
policy). 


Continued  on  next  page 
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The  Operational  Framework,  Continued 


Rationale  for 
the  operation 
framework, 
continued 


Impact  on  SPF 
organization 


•  Identify  and  use  only  the  relevant  information  for  each  part:  Only  relevant 
information  needs  to  be  in  each  part  of  the  operational  framework.  For  example, 
training  information  should  only  be  in  training  documents,  and  policies  should 
contain  information  that  does  not  change  frequently.  By  placing  only  relevant 
information  in  each  part  of  the  operational  framework,  people  will  learn  where  to 
look  for  information. 

•  Manage  changes  and  improvements:  Changes  and  improvements  to  the 
operational  parts  will  be  easier  to  manage  because  the  information  is  well 
defined.  For  example,  once  defined,  policies  should  not  frequently  change. 
Processes  probably  do  not  need  to  change  if  a  step  by  step  procedure  changes. 
Training  changes  can  be  isolated  to  training  documents.  Only  the  necessary  and 
important  relationships  between  the  operational  parts  need  to  be  managed. 

•  Manage  and  improve  communication:  Communication  improves  because 
people  know  where  to  look  for  certain  types  of  information,  and  they  know  the 
relationships  between  the  information.  Since  the  changes  are  isolated  to  the 
operational  parts,  less  communication  is  needed  and  only  the  relevant  changes 
need  to  be  managed  and  communicated. 


Within  each  maturity  level  of  the  CMM,  the  SPF  is  organized  according  to  the 
operational  framework.  Therefore,  each  maturity  level  is  presented  with  separate 
sections  for: 

•  policies 

•  standards, 

•  processes,  and 

•  procedures. 

Note:  Training  and  tools  are  closely  related  to  processes  and  are  presented  as 
checklists  with  the  process  they  support. 
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Chapter  2.  Features  of  the  Software  Process  Framework 
Overview 


Chapter 

purpose 


The  purpose  of  this  chapter  is  to  describe  the  features  of  the  Software  Process 
Framework  (SPF). 


In  this  chapter  This  chapter  discusses  the  following  features: 


Feature 

See  Page 

Checklists 

Features-2 

CMM  context 

Features-4 

CMM  reference  text 

Features-5 

CMM  role  identification 

Features-8 

Entry  and  exit  criteria 

Features-9 

Translation  tables 

Features-1 1 

User  references 

Features- 15 
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Checklists 


Introduction 


Types  of 
checklists 


The  SPF  presents  information  in  checklists,  which  provide  various  perspectives  of 
the  recommendations  made  by  the  CMM.  Organizations  can  use  these  checklists 
to  compare  their  process  documentation  to  the  CMM. 

The  purpose  of  this  section  is  to  describe  how  the  checklists  in  the  SPF  can  be 
used. 


There  are  five  types  of  checklists  in  the  SPF.  Tneir  names  and  descriptions  are 
provided  below. 


Checklist  Type 

Description 

Policy 

Describes  the  policy  contents  and  KPA  goals  recommended 
by  the  CMM. 

Standard 

Describes  the  recommended  content  of  select  wo±  products 
described  in  the  CMM. 

Process 

Describes  the  process  information  content  recommended  by 
the  CMM.  The  process  checklists  are  further  refined  into 
checklists  for: 

•  roles, 

•  entry  criteria, 

•  inputs, 

•  activities, 

•  outputs, 

•  exit  criteria, 

•  reviews  and  audits, 

•  work  products  managed  and  controlled, 

•  measurements, 

•  documented  procedures, 

•  training,  and 
’  tools. 

Procedure 

Describes  the  recommended  content  of  documented 
procedures  described  in  the  CMM. 

Level  Overview 

Provides  an  overview  of  an  entire  maturity  level.  The  level 
overview  checklists  are  further  refined  into  checklists  for: 

•  KPA  purposes, 

•  KPA  goals, 

•  policies, 

•  standards, 

•  process  descriptions, 

•  procedures, 

•  training, 

•  tools, 

•  reviews  and  audits, 

•  work  products  managed  and  controlled,  and 

•  measurements. 

Continued  on  next  page 
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Checklists,  continued 


Use  A  checklist  is  used  to; 

•  allow  process  designers,  analyzers,  or  reviewers  to  check  whether  their  software 
processes  are  consistent  with  the  CMM. 

•  indicate  that  a  particular  item  is  being  addressed  by  the  organization. 


Example  of  use  The  following  example  illustrates  how  the  SPF  checklists  are  used  to  show 

consistency  with  the  CMM,  and  illustrate  compliance  and  noncompliance  with 
specific  CMM  recommendations.  As  shown  in  the  example  below,  a  check  (v)  in 
the  left  column  is  used  to  indicate  that  a  role  has  been  completely  satisfied. 

The  checkboxes  are  used  when  there  are  checklists  within  checklists  (nested 
checklists).  When  there  are  nested  checklists,  the  left  column  becomes  the  parent 
checklist.  Only  check  the  parent  checklist  if  all  the  checkboxes  in  that  parent  are 
satisfied. 

In  the  example  below,  the  SCCB  role  is  not  satisfied  (the  parent  checklist  is  not 
checked)  because  all  of  the  checkboxes  within  that  parent  have  not  been  checked. 
Only  the  project  manager  role  has  been  completely  satisfied  (indicated  by  the 
check  in  the  left  column). 


Roles 

The  table  below  describes  the  activities  that  are  performed  by  the  CMM  roles  in  the 
software  configuration  management  process. 


T 

Role 

Activity 

Reference 

V 

Project 

Manager 

The  SCM  activities  are  reviewed  with  the 
project  manager  on  both  a  periodic  and 
event-driven  basis.  {L2-83,V2) 

VI  S5.2 

SCCB 

The  SCCB:  (U-73,Abl) 

□  Authorizes  the  establishment  of 
software  baselines  and  the 
identiricadon  of  configuradon 
items/units. 

VI  S4.6.2 

(3l  Represents  the  interests  of  the 

prefect  manager  and  all  groups  who 
may  be  affected  by  changes  to  the 
software  baselines. 

VJ  S4.6 

□f  Reviews  and  authorizes  changes  to 
the  software  baselines. 

VI  S4.6.2a 

O  Authorizes  the  cieation  of  products 
from  the  software  baseline  library. 

VI  S4.6.2.b 
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CMM  Context 


Introduction 

Indicating 
added  context 

Example 


There  are  many  places  where  extracting  a  passage  from  the  CMM  results  in  lost 
context.  This  section  describes  how  CMM-specific  context  within  the  SPF  is 
provided. 


Parentheses  are  used  to  provide  CMM-specific  context  within  the  SPF. 


The  following  example  from  the  intergroup  coordination  key  process  area  shows 
the  use  of  parentheses  to  maintain  context: 


1C  Process  -  Inputs 


Inputs  The  table  below  lists  the  recommended  inputs  to  the  intergroup  coordination 

process. 


Context 

added 

Input 

Org.  Input 

References 

Actual  completion  (of  cntical 
dependencies)  (L3-89,  A4. 5. 1 ) 

Changes  to  intergroup  commitments.  (L3  - 
88,  A3, 4) 

Changes  to  the  plan  (used  to  communicate 
tntergroup  commttments  and  to  coordinate 
and  track  the  work  performed)  (L3-88, 

A3, 5) 

Changes  to  the  project-level  objecuves 
(U-^,  A-.t,  1.2) 

Changes  to  the  system  requirements.  (L3  • 
87|  Az.  1 .2) 

Commitments  (L3-90,  A7, 4) 

Customer’s  requirements  (L3-87,  Al,  1) 

End  users  requirements  (L3-87,  Al,  1) 

Intergroup  commitments.  (L3-88.  A3) 

Plan  (used  to  communicate  intergroup 
commitments  and  to  coordinate  and  track 
the  work  performed).  (L3-88,  A3) 

Project  schedule.  (L3-89,  A4. 3) 

Projected  compleuon  (of  critical 
dependencies).  (L3-89.  A4. 5.1) 

^■ftware  schedule.  fI.3.R9j  A4.  3) 

Stati^(of  cntical  dependencies)7^3-89. 
A4.5>~- _ _ 

System  requirements.  (L3-90.  A7. 3) 

Technical  issues  (L3-90.  A7. 5) 

Technical  requirements.  (L3-90.  A7, 3) 

_ 

Technical  risks  (L3-88.  A2.  1  4) 
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CMM  Reference  Text 


Introduction 


Deflnition 


Expected  use 


Syntax 


Example: 

CMM  reference 
text 


The  ability  to  trace  from  process  documentation  to  the  CMM  is  essential  for 
software  organizations.  This  section  describes  the  convention  used  to  cross- 
reference  information  items  of  the  SPF  to  the  CMM  source  documentation. 


CMM  reference  text  identifies  the  location  of  the  CMM  source  material  from  which 
the  SPF  derives  its  information. 


CMM  reference  text  is  used  to: 

•  Identify  a  passage  in  the  CMM  quickly. 

•  Maintain  traceability  from  organizational  process  documentation  to  the  CMM. 


The  syntax  of  CMM  reference  text  is: 

([CMM  page],  [Key  practice],  [Subpractice]. [Subpractice  subbullet]) 


This  is  an  example  of  CMM  reference  text. 


CMM  page 

number  Subpractice 

I  \  /, 

(L2-7,  A3, 1.1) 

I — 

Key  practice  Subpraclice 

subbullet 

Note:  Text  which  spans  page  boundaries  of  the  CMM  is  referenced  by  the  first 
page  only. 


Continued  on  next  page 
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CMM  Reference  Text,  Continued 


Abbreviations: 
Key  practices 


The  abbreviations  used  for  the  key  practice  component  of  the  CMM  reference  text 
are  listed  in  the  table  below. 


CMM  Common  Features  (key  practice  type) 

Abbreviation 

Goal  (not  a  common  feature,  but  added  as  an  SPF  abbreviation) 

G 

Commitment  to  perform 

C 

Ability  to  perform 

Ab 

Activity  performed 

A 

Measurement  and  analysis 

M 

Verifying  implementation 

V 

Note:  These  abbreviations  are  always  followed  by  a  number  denoting  the  number 
associated  with  the  key  practice. 

Example:  Activity  3  of  Requirements  Management  is  found  on  page  L2- 
7,  so  the  CMM  Reference  text  would  be  (L2-7,  A3). 


Continued  on  next  page 
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CMM  Reference  Text,  Continued 


Example: 
CMM  page 
with  SPF 
references 


The  following  diagram  shows  a  page  from  the  CMM.  Examples  of  CMM 
reference  text  are  shown  as  boxed  examples. 


I  Level  2:  Repeatable 


Requirements  Management 


(Activity  2)  The  allcxrated  requirements: 

1.  Are  managed  and  controlled . 


T/ianaged  and  controlled"  implies  that  the  version  of  the  work 
product  in  use  at  a  given  time  (past  or  present)  is  known  (i.e., 
version  control),  and  changes  are  incorporated  in  a  controlled 
manner  (i.e.,  change  control). 

If  a  greater  degree  of  formality  than  is  implied  by  "managed  and 
controlled"  is  desired,  the  work  product  can  be  placed  under  the 
full  discipline  of  configirration  management,  as  is  described  in  the 
Software  Configuration  Management  key  process  area. 


2.  Are  the  basis  for  the  software  development  plan. 

L2-7.  A3)  I  developing  the  software  requirements. 


Activity  3  Changes  to  the  allocated  requirements  are  reviewed  and 

incorporated  into  the  software  project. 

I(L -7  A3  111-**  ^  ^ impact  to  existing  conunitments  is  assessed,  and  changes  are 
L:.,-'  ’  ’  'I  negotiated  as  appropriate. 

□  Changes  to  comnutments  made  to  individuals  and  groups 
W  external  to  the  organization  are  reviewed  with  senior 
management . 


Refer  to  Activity  4  of  the  Software  Project  Planning  key  process 
area  and  Activity  3  of  the  Software  Project  Tracking  and 
Oversight  key  process  area  for  practices  covering  commitments 
made  extenrd  to  the  organization. 


|(L2-7.  A3,  1.1) 
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□  Changes  to  commitments  within  the  organization  are  negotiated 
tvith  the  affected  groups. 
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CMM  Role  Identification 


Introduction 


Definition: 
Types  of  roles 


Identification: 
Active  roles 


Identification: 
Passive  roles 


Exan?ple 


The  CMM  identifies  many  roles.  This  section  describes  how  the  SPF  highlights  the 
roles  found  in  the  CMM.  This  feature  should  help  you  use  the  SPF  to  determine 
the  responsibilities  of  each  role  defined  in  the  CMM. 


The  SPF  defines  roles  as  active  or  passive  depending  on  the  context  given  in  the 
CMM.  The  following  table  provides  the  basis  for  defining  a  particular  appearance 
of  a  role  as  active  or  passive. 


IF  the  occurrence... 

THEN  the 
role  is... 

Example 

refers  to  an  activity  the  role 
participate  in 

Active 

The  software  quality 
assurance  group  reviews 
and/or  audits  the... 

indicates  the  existence  of  a  role 

Passive 

A  group  that  is  responsible 
for  coordinating  and 
implementing  ...  exists. 

is  modifying  a  work  product 

Passive 

Subcontractor’s  plans. 

The  SPF  uses  bold  typeface  to  indicate  the  occurrence  of  an  active  role. 

Note:  In  the  roles  checklist,  only  the  role  being  described  is  presented  in  bold 
typeface. 


The  SPF  uses  normal  typeface  for  occurrences  of  passive  roles. 


The  following  example  illustrates  the  use  of  bold  typeface  in  the  SPF. 

Example;  The  organization's  activities  for  defect  prevention  are  reviewed  with 
senior  management  on  a  periodic  basis.  (L5-14,  VI) 
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Entry  and  Exit  Criteria 


Deflnitions 


Note 


Types  of 
criteria 


Entry  criteria  are  the  conditions  under  which  an  activity  can  be  started.  Entry 
criteria  often  take  the  form  of  a  simple  or  compound  predicate  about  the  state  of  a 
work  product,  role,  or  activity. 

Example; _ 


Input 

State 

Allocated 

requirements 

are  documented.  (L2-3,  Cl,l) 

Exit  criteria  are  the  conditions  under  which  an  activity  can  be  declared  complete. 
Exit  criteria  often  take  the  form  of  a  simple  or  compound  predicate  about  the  state 
of  an  artifact,  role,  or  activity. 

Example:  _ _ 


Output 

State 

Project's  software 
development  plan 

includes  defect  prevention  activities. 
(L5-3,  C2,  1) 

Many  of  the  key  process  areas,  once  started,  end  when  the  project  (or 
organization!)  ends.  For  these  processes,  one  way  to  evaluate  whether  exit  criteria 
are  being  met  by  the  process  description  is  to  answer  the  following  question: 

If  the  process  was  executed  as  described,  would  it  result  in  the  exit  criteria  being 
satisfied? 


Entry  and  exit  criteria  have  each  been  partitioned  into  two  types  —  input  and 
output  based  and  general.  The  major  determinant  for  the  type  of  criteria  is  state 
information.  State  refers  to  the  status  of  a  work  product  when  entering  (entry 
state)  or  exiting  (exit  state)  a  process. 


Continued  on  next  page 
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Entry  and  Exit  Criteria,  Continued 


Description: 
Entry  criter.  i 


Description: 
Exit  criteria 


We  used  the  following  rule  to  determine  whether  entry  criteria  were  input  based  or 
general. 

Note:  The  examples  are  taken  from  the  requirements  management  key  process 
area. 


IF  the  criteria  contain  state 
information  about  an... 

THEN  they  are... 

Example 

input 

input-based  entry 
criteria 

Input:  Allocated 

requirements 

State:  are  documented. 

activity  or  role 

general  entry 
criteria 

The  project  follows  a  written 
organizational  policy  for 
managing  the  system 
requirements  allocated  to 
software. 

We  used  the  following  rule  to  determine  whether  exit  criteria  were  output-based  or 
general. 

Note:  The  examples  are  taken  from  the  requirements  management  key  process 
area. 


IF  the  criteria  contain  state 
information  about  an... 

THEN  they  are... 

Example 

input 

general  exit 
criteria 

The  allocated  requirements 
are  reviewed,  and  problems 
are  resolved  before  the 
software  engineering  group 
commits  to  diem. 

output 

output-based  exit 
criteria 

Output:  Commitments 

resulting  from  the 

allocated 

requirements 

State:  are  negotiated  with 
the  affected  groups. 

activity  or  role 

general  exit 
criteria 

The  activities  for  managing 
the  allocated  requirements 
are  reviewed  with  senior 
management  on  a  periodic 
basis. 
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Translation  Tables 


Purpose 


Rationale 


In  this  section 


The  purpose  of  the  translation  tables  is  to  provide  an  organization  with  a  tool  to 
translate  CMM  terminology  into  their  own  terminology. 


Making  the  translation  assumptions  explicit  has  proven  to  be  beneficial  in  practice. 
Experience  has  shown  that  there  is  rarely  a  one-to-one  mapping  of  terminology, 
and  there  are  usually  “gray"  areas  that  should  be  documented.  There  can  also  be 
different  terminology  within  the  same  organization  (e.g.,  projects  or  divisions 
within  the  same  organization  may  use  different  terminology). 


This  section  describes  three  types  of  translation  tables. 


Translation  table 

Page 

Role  translation  table 

Features- 12 

General  term  translation  table 

Features- 13 

Work  product  translation  table 

Features- 14 
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Role  translation  table 


Introduction 

Location 

When  to  use 

Use 

Guidance 

Example 


In  order  to  be  widely  applicable,  the  CMM  uses  roles  that  are  not  specific  to  one 
organizational  structure.  The  role  translation  table  provides  the  ability  to  map 
generic  CMM  roles  to  the  roles  found  in  your  organization. 


The  role  translation  tables  are  located  in  Appendix  C  of  the  SPF. 


The  role  translation  table  is  typically  used  first  in  any  activity  involving  the  SPF. 


To  use  the  role  translation  table,  simply  read  the  CMM  role  from  the  left  column 
of  the  table  and  list  the  equivalent  role(s)  from  your  organization  in  the  right 
column. 


Completing  the  role  translation  table  may  be  an  iterative  activity.  For  example,  if 
you  are  addressing  only  one  KPA,  then  you  should  only  complete  the  table  for  the 
roles  identified  in  that  KPA. 

Note:  The  roles  checklist  included  in  each  KPA  section  of  the  SPF  indicates  the 
roles  involved  m  a  particular  KPA. 


The  following  table  provides  an  excerpted  example  of  a  role  translation  table. 


CMM  Role 

Your  Organization’s  Role(s) 

Affected  groups  or  other  affected 
groups 

SQA 

SCM 

Marketing 

Sales 

Technical  staff 

Testing  department 

And  so  on... 

Project  manager 

Project  leader 

Project  software  manager 

Project  leader 

Senior  management 

Senior  management  steering  committee 

Software  engineering  process  group 

SEPG 

Senior  manager 

CEO 

Software  engineering  staff 

Technical  staff 
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General  Term  Translation  Table 


Introduction 

Location 

When  to  use 

Use 

Example 


Since  the  CMM  is  broadly  applicable,  it  is  unavoidable  that  some  terms  will  need  to 
be  further  defined  for  each  organization.  The  general  term  translation  tables  are  a 
tool  for  translating  general  terms  used  by  the  CMM  into  organization-specific 
terminology. 


The  general  term  translation  tables  are  located  in  Appendix  D  of  the  SPF. 


The  general  term  translation  table  is  used  early  in  any  activity  involving  the  SPF, 
typically  after  performing  role  translations. 


To  use  the  general  term  translation  table,  simply  read  the  CMM  general  term  from 
the  left  column  of  the  table  and  list  the  equivalent  term  from  your  organization  in 
the  right  column. 


The  following  table  provides  an  excerpted  example  of  a  general  term  translation 
table. 


CMM  General  Terms 

Your  Organization’s  Terms 

Product 

Deliverable 

Project 

Project 

Software  product 

CSCI/CSCU 

Software  project 

Software  task 

System 

Product 
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Work  Product  Translation  Table 


Purpose 


Note 


Location 


When  to  use 


Use 


Example 


The  woric  product  translation  tables  provide  the  ability  to  translate  CMM  names  for 
work  products  into  your  organization’s  terminology. 


There  are  two  types  of  work  product  translation  tables.  They  are: 

•  input  translation  tables,  and 

•  output  translation  tables. 


The  work  product  translation  tables  are  embedded  as  part  of  the  input  and  output 
checklists  for  each  key  process  area. 


Work  product  translation  tables  should  be  completed  when  the  process  inputs  and 
outputs  are  being  addressed. 


Use  the  following  procedure  for  completing  the  woric  product  translation  tables. 


Step 

Action 

1 

Read  the  CMM  work  product  from  the  input  or  output  column  of  the 
checklist,  and  list  the  equivalent  organization  woric  product(s)  in  the 
“Org.  Input”  (for  inputs)  or  “Org.  Output”  (for  outputs)  column  in 
the  checklist. 

2 

Place  a  reference  to  the  organization’s  procfc-^s  documentation  for  that 
work  product  in  the  references  column  of  the  SPF. 

3 

Repeat  steps  1  and  2  for  the  rest  of  the  table. 

The  following  table  provides  an  excerpted  example  of  an  input  translation  table 
from  the  requirements  management  process  translating  CMM  inputs  into  a 
fictitious  organization’s  inputs.  Output  translations  would  result  in  similar  results. 


T 

Input 

Org.  Input 

References 

✓ 

Statement  of  Work.  (L2-14,  Abl) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  a  statement  of 
work.] 

SOW 

DID  1000.5 

Allocated  requirements.  (L2-18,  A6,  1.4) 

SRS 

DID  1000.6 

✓ 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  allocated 
requirements.] 

IRS 
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User  References 


Introduction 


Expected  use 


In  addition  to  tracing  process  documentation  back  to  the  CMM,  it  is  also  important 
for  organizations  to  trace  from  the  SPF  to  their  process  documentation.  This 
section  describes  the  feature  that  provides  this  capability. 


User  references  are  used  to: 

•  Identify  the  location  of  the  organizational  process  documentation  that  addresses 
a  process  element  in  the  SPF. 

•  Indicate  the  suggested  location  of  the  organizational  process  documentation  that 
should  address  a  process  element  in  the  SPF  that  is  not  currently  being  addressed 
by  the  organization. 

•  Provide  traceability  from  organizational  process  documentation  to  the  SPF,  and 
therefore,  to  the  CMM. 


Continued  on  next  page 
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User  References,  continued 


Example 


Consider  the  following  scenario: 

A  user  is  reviewing  an  organizational  document  against  the  SPF  and  wants 
traceability  (from  the  SPF  to  the  organizational  document).  The  user  places  a 
reference  to  the  organizational  document  in  the  “References”  column  (e.g., 
chapter,  section,  page,  paragraph)  of  the  SPF.  Abbreviations  are  used  since  blank 
space  is  limited,  and  there  are  numerous  reference  boxes  to  fill  in. 

In  the  example  below,  “VI”  is  an  abbreviation  for  “Volume  1”;  “V2”  is  an 
abbreviation  for  “Volume  2”;  and  “S”  is  an  abbreviation  for  “Section.”  In  this 
example,  the  numbers  allow  traceability  to  the  exact  page  and  subsection  of  the 
hypothetical  organizational  document. 


SCM  Process  -  Exit  Criteria  ,  Continued 


Output-based  The  table  below  describes  the  states  that  outputs  must  satisfy  to  exit  the  software 
Exit  Criteria,  conriguration  management  process,  continued  from  the  previous  page, 
continued  _  _  _  _ _ 


T 

Output 

State 

References 

SCM  plan 

IB’ 

development  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

VI  32.3.6 

S' 

distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75.  Ab2, 2) 

VI  S2.3.6 

□ 

maintenance  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75.  Ab2,  2) 

VI  S2.3.6 

ar 

is  prepared  for  each  software 
project  according  to  a 
documented  procedure.  (L2-76, 
Al) 

V2SJ.J 

Bf 

is  developed  in  the  early  stages 
of,  and  in  parallel  with,  overall 
project  planning.  (L2-76,  Al,  1) 

V2  SI.2 

is  reviewed  by  the  affected 
groups.  (L2-77,  Al,2) 

V2  SI.3 

S’ 

is  managed  and  controlled.  (L2  - 
77.  Al,3) 

V2  SI. 4 

□ 

is  d(  ..'umented.  (L2-77,  A2) 

V2SI.5 

□ 

is  approved.  (L2-77,  A2) 

V2SI6 

□ 

is  used  as  the  basis  for 
performing  the  SCM  activities 
(L2-77,  A2) 

V2S1.7 

Cont  iiued  on  next  page 
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User  References,  Continued 


References  to 

unchecked 

items 


Notice  that  there  can  be  references  to  items  in  the  checklist  that  are  not  checked. 
These  references  can  be  used  as  pointers  to  areas  of  the  organizational  document 
that  can  be  improved. 


Example;  The  previous  checklist  contains  several  items  that  are  not  satisfied.  The 
references  serve  as  pointers  to  the  location  in  the  organizational  process 
documentation  where  improvements  might  be  made  in  the  future. 
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Chapter  3.  How  to  Use  the  Software  Process  Framework 
Overview 


Chapter 

purpose 


Before  you 
begin 


Assumptions 


Evolution  of 
this  chapter 


The  purpose  of  this  chapter  is  to  provide  guidance  on  how  to  use  the  Software 
Process  Framework  (SPF). 


Before  reading  this  section,  you  will  want  to  become  familiar  with  the  features  of 
the  SPF.  Please  refer  to  Chapter  2,  Features  of  the  SPF,  for  further  information. 


The  audience  using  the  SPF  is  expected  to  be  experienced  in  software  process 
definition  and  improvement  and  familiar  with  the  concepts  and  terminology  of  the 
CMM  (e.g.,  software  engineering  process  groups,  process  engineers,  process  action 
teams,  software  quality  assurance  groups,  etc). 


This  chapter  contains  guidance  for  using  the  SPF  to  analyze  and  review  software 
processes.  Additional  data  are  currently  being  collected  and  future  versions  of  this 
document  will  provide  additional  guidance. 
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Using  the  SPF  to  Analyze  and  Review  Software  Processes 


Introduction 


Before  you 
begin 


Suggestion 


What  you  need 


Many  organizations  develop  baselines  of  their  current  software  processes.  After 
the  baseline  is  developed,  it  is  useful  to  be  able  to  analyze  it  for  consistency  with 
the  CMM. 

This  section  provides  guidance  for  analyzing  and  reviewing  existing  process 
documentation  for  consistency  with  the  CMM. 


Before  you  begin  this  procedure,  you  should  identify  the  scope  ot  tlie  process 
document  you  are  analyzing  or  reviewing.  For  w  tample,  the  scope  of  your 
document  could  be: 

•  an  entire  process  document, 

•  organizational  policle.*:, 

•  organization  standards, 

•  the  software  project  planning  KPA,  or 

•  the  recommended  training  for  level  4. 


It  is  helpful  to  make  photocopies  of  the  appropriate  material  from  the  SPF  prior  to 
beginning  this  procedure  (i.e.,  keep  a  good  master!).  For  example,  if  you  were 
reviewing  organizational  policies  against  those  recommended  at  level  2,  then  you 
would  make  copies  of  the  SPF  level  2  policy  checklists. 


To  complete  this  procedure,  you  will  need: 

•  Role  translation  tables. 

•  General  term  translation  tables. 

•  The  appropriate  checklists  from  the  SPF,  depending  on  the  scope  selected. 

•  Work  product  translation  tables  (optional), 

•  The  process  documentation  to  be  analyzed  or  reviewed. 


Continued  on  next  page 
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Using  the  SPF  to  Analyze  and  Review  Software  Processes, 

Continued 


Procedure  Use  this  procedure  to  analyze  and  review  process  documentation. 


Step 

Action 

1 

Use  the  role  translation  table  to  translate  CMM  roles  into  your 
organization’s  roles.  (See  “Role  Translation  Table”  in  chapter  2  and 
Appendix  C  for  blank  tables.) 

2 

Use  the  general  term  translation  table  to  translate  CMM  general  terms 
into  organizational  terminology.  (See  “General  Term  Translation 
Tables”  in  chapter  2  and  Appendix  D  for  templates.) 

3 

Use  the  work  product  translation  tables  to  translate  the  CMM  work 
products  into  organizational  work  products.  (See  “Work  Product 
Translation  Tables”  in  chapter  2  and  the  input  and  output  checklists 
in  the  appropriate  KPA  section  of  the  SPF) 

4 

Select  an  item  from  the  SPF  checklist  that  has  not  been  analyzed  or 
reviewed. 

IF:  the  item  is  satisfied  (i.e.,  your  organization’s  process 

description  addresses  the  item  being  considered) 

THEN:  check  the  checkbox  next  to  the  item.  (See  chapter  2  for 
guidance  on  completing  the  checklists) 

record  the  reference  to  the  organizational  process  document 

IF:  the  item  is  not  satisfied  (i.e.,  your  organization’s  process 

description  does  not  address  the  item  being  considered) 

THEN:  do  not  check  the  checkbox  next  to  the  item. 

record  the  reference  of  where  in  the  process  document  the 
item  probably  should  be  addres.sed,  if  possible.  (This  is 
helpful  for  improving  the  document  or  process  being 
evaluated.) 

IF:  the  item  does  not  apply  to  your  orgc.nization  (e.g.,  if  your 

organization  doesn’t  subcontract  out  software,  then  items 
related  to  software  subcontractors  probably  do  not  apply  to 
your  organization) 

THEN:  mark  N/A  in  the  checkbox  next  to  item. 

if  possible,  record  the  rationale  (or  pointer  to  the  rationale) 
in  the  user  reference  column. 

5 

IF:  there  are  more  items  in  the  SPF  checklist  to  analyze  or 

review 

THEN:  go  to  step  4. 

ELSE:  the  analysis  or  review  is  complete. 

Continued  on  next  page 
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Using  the  SPF  to  Analyze  and  Review  Software  Processes, 

Continued 


Results  When  the  analysis  or  review  is  completed,  you  will  have: 

•  Completed  checklists  of  the  CMM  recommendations  that  are  satisfied  and 
unsatisfied. 

•  A  list  of  CMM  recommendations  that  do  not  apply  to  your  organization,  with  (if 
recorded)  rationale  of  why  they  do  not. 


Next  steps  If  all  CMM  criteria  are  satisfied,  then  the  process  document  is  consistent  with  the 

CMM. 

Caution:  Do  not  interpret  this  as  implying  a  particular  maturity  rating.  The  SPF 
is  a  measure  of  consistency  of  process  documentation.  Other  factors 
such  as  actual  practice  are  not  measured  by  the  SPF. 

CMM  recommendations  that  are  not  satisfied,  and  have  no  rationale  for  why  they 
are  not,  become  a  starting  point  for  process  improvement  efforts. 


Usage-4 
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Chapter  4.  Repeatable  Level  (Level  2) 
Overview 


Introduction  This  chapter  contains  the  checklists  for  level  2  of  the  CMM. 


In  this  chapter  This  chapter  contains  the  following  sections: 


Level  2  Policy  Checklists 
Overview 


introduction 


Purpose 


Checklist 

description 


In  this  section 


This  section  describes  the  explicit  policies  found  in  the  Capability  Maturity  Model 
at  maturity  level  2. 


The  purpose  of  the  policy  checklists  is  to  provide: 

•  Guidance  in  identifying  which  policies  are  recommended  by  the  CMM  at  level  2. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  policies  to  determine 
if  they  are  consistent  with  the  CMM  at  level  2. 

•  Information  that  can  be  used  to  develop  software  policies  so  that  they  are 
consistent  with  the  CMM  at  level  2. 


Each  checklist  contains  two  subsections:  the  KPA  policies  and  the  KPA  goals.  The 
table  below  describes  these  two  subsections  of  a  policy  checklist. 


Subsection 

Description 

Policy  checklist 

This  subsection  contains  criteria  that  the  organizational 
policy  can  be  evaluated  against.  These  criteria  must  be 
addressed  by  organizational  policy  to  be  consistent  with  the 
CMM. 

Policy  goals 

This  subsection  is  a  reminder  to  policy  designers  and 
evaluators  to  keep  in  mind  the  KPA  goals  when  developing 
the  policies  for  each  KPA.  The  goals  can  be  thought  of  as 
the  results  of  implementing  an  effective  policy. 

This  section  covers  the  following  policies: 


Policies 

See  Page 

Requirements  management  policy 

L2-Policy-2 

Software  project  planning  policy 

L2-Policy-3 

Software  project  tracking  and  oversight  policy 

L2-Policy-4 

Software  subcontract  management  policy 

L2-Policy-5 

Software  quality  assurance  policy 

L2-Policy-6 

Software  configuration  management  policy 

L2-Policy-7 
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Requirements  Management  (RM)  Policy 


RM  policy 
checklist 


RM  policy 
goals 


The  project  follows  a  written  organizational  policy  for  managing  the  system 
requirements  allocated  to  software  (L2-2,  Cl).  This  policy  typically  specifies  that: 


T 

Description 

References 

The  allocated  requirements  are  documented.  (L2-3,  Cl,  1) 

The  allocated  requirements  are  reviewed  by:  (L2-3,  Cl,  2) 

□  the  software  managers,  and 

□  other  affected  groups. 

The  software  plans,  work  products,  and  activities  are  changed 
to  be  consistent  with  changes  to  the  allocated  requirements. 
(L2-3,  Cl,  3) 

Implementation  of  an  effective  requirements  management  policy  has  the  following 
results: 


'T 

Results  of  Effectively  Implementing  RM  Policy 

References 

System  requirements  allocated  to  software  are  controlled  to 
establish  a  baseline  for  software  engineering  and 
management  use.  (L2-2,  Gl) 

Software  plans,  products,  and  activities  are  kept  consistent 
with  the  system  requirements  allocated  to  software.  (L2-2, 
G2) 

L2-Policy-2 
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Software  Project  Planning  (SPP)  Policy 


SPP  policy 
checklist 


SPP  policy 
goals 


The  project  follows  a  written  organizational  policy  for  planning  a  software  project 
(  L2-12,  C2).  This  policy  typicdly  specifies  that: 


T 

Description 

References 

The  system  requirements  allocated  to  software  are  used  as 
the  basis  for  planning  the  software  project.  (L2-12,  C2,  1) 

Tne  software  project’s  commitments  are  negotiated  between: 
(L2-12,  C2.  2) 

□  the  project  manager, 

□  the  project  software  manager,  and 

□  the  other  software  managers. 

Involvement  of  other  engineering  groups  m  the  software 
activities  is  negotiated  with  these  groups  and  is  documented. 
(L2-13,  C2.  3) 

Affected  groups  review  the  project's:  (L2-13,  C2, 4) 

□  software  size  estimates, 

□  effort  and  cost  estimates, 

□  schedules,  and 

□  other  commitments. 

Senior  management  reviews  all  software  project 
commitments  made  to  individuals  and  groups  external  to  the 
organization.  (L2-13,  C2,  5) 

The  project's  software  development  plan  is  managed  and 
controlled.  (L2-13,  C2,  6) 

Implementation  of  an  effective  software  project  planning  policy  has  the  following 
results: 


Results  of  Effectively  Implementing  SPP  Policy 

References 

Software  estimates  are  documented  for  use  in  planning  and 
tracking  the  software  project.  (L2-12,  Gl) 

Software  project  activities  and  commitments  are  planned  and 
documented.  (L2-12,  G2) 

Affected  groups  and  individuals  agree  to  their  commitments 
related  to  the  software  project.  (L2-12,  G3) 
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Software  Project  Tracking  and  Oversight  (SPTO)  Policy 


i’TO  policy  The  project  follows  a  written  organizational  policy  for  managing  the  software 
checklist  project  (L2-30,  C2).  This  policy  typically  specifies  that: 


T 

Description 

References 

A  documented  software  development  plan  is  used  and 
maintained  as  the  basis  for  tracking  the  software  project. 
(L2-30,  C2,  1) 

The  project  manager  is  kept  informed  of  the  software 
project's  status  and  issues.  (L2-30,  C2, 2) 

Corrective  actions  are  taken  when  the  software  plan  is  not 
being  achieved,  either  by  adjusting  performance  or  by 
adjusting  the  plans.  (L2-30,  C2,  3) 

Changes  to  the  software  commitments  are  made  with  the 
involvement  and  agreement  of  the  affected  groups.  (L2-30, 
C2.4) 

Senior  management  reviews  all  commitment  changes  and 
new  software  project  commitments  made  to  individuals  and 
groups  external  to  the  organization.  (L2-31,  C2,  5) 

SPTO  policy  Implementation  of  an  effective  software  project  tracking  and  oversight  policy  has 
goals  the  following  results: 


T 

Results  of  Effectively  Implementing  SPTO  Policy 

References 

Actual  results  and  performances  are  tracked  against  the 
software  plans.  (L2-30,  Gl) 

Corrective  actions  are  taken  and  managed  to  closure  when 
actual  results  and  performance  deviate  significantly  from  the 
software  plans.  (L2-30,  G2) 

Changes  to  software  commitments  are  agreed  to  by  the 
affected  groups  and  individuals.  (L2-30,  G3) 

L2-Policy-4 
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Software  Subcontract  Management  (SSM)  Policy 


SSM  policy 
checklist 


SSM  policy 
goals 


The  project  follows  a  written  organizational  policy  for  managing  the  software 
subcontract  (L2-44,  Cl).  This  pwlicy  typically  specifies  that:, 


T 

Description 

References 

Documented  standards  and  procedures  are  used  in  selecting 
software  subcontractors  and  managing  the  software 
subcontracts.  (L2-45,  Cl,  1) 

The  contractual  agreements  form  the  basis  for  managing  the 
subcontract.  (L2-45,  Cl,  2) 

Changes  to  the  subcontract  are  made  with  the  involvement 
and  agreement  of  both  the  prime  contractor  and  the 
subcontractor.  (L2-45,  Cl,  3) 

Implementation  of  an  effective  software  subcontract  management  policy  has  the 
following  results: 


V 

Results  of  Effectively  Implementing  SSM  Policy 

References 

The  prime  comractor  selects  qualified  software 
subcontractors.  (L2-44,  Gl) 

The  prime  contractor  and  the  software  subcontractor  agree 
to  their  commitments  to  each  other.  (L2-44,  G2) 

The  prime  contractor  and  the  software  subcontractor 
maintain  ongoing  communications.  (L2-44,  G3) 

The  prime  contractor  tracks  the  software  subcontractor's 
actual  results  and  performance  against  its  commitments. 
(L2-44,  G4) 
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Software  Quality  Assurance  (SQA)  Policy 


SQA  policy 
checklist 


SQA  policy 
goals 


The  project  follows  a  written  organizational  policy  for  implementing  software 
quality  assurance  (L2-60,  Cl).  This  policy  typically  specifies  that: 


Description 

References 

The  SQA  function  is  in  place  on  all  software  projects.  (L2- 
60,  Cl,  1) 

The  SQA  group  has  a  reporting  channel  to  senior 
management  that  is  independent  of:  (L2-61,  Cl,  2) 

□  the  project  manager, 

□  the  project's  software  engineering  group,  and 

□  other  software-related  groups. 

Senior  management  periodically  reviews  the  SQA  activities 
and  results.  (TL2-61,  Cl,  3) 

Implementation  of  an  effective  software  quality  assurance  policy  has  the  following 
results: 


nr 

Results  of  Effectively  Implementing  SQA  Policy 

References 

Software  quality  assurance  activities  are  planned.  (L2-60, 

Gl) 

Adherence  of  software  products  and  activities  to  applicable 
standards,  procedures,  and  requirements  is  verified 
objectively.  (L2-60,  G2) 

Affected  groups  and  individuals  are  informed  of  software 
quality  assurance  activities  and  results.  (L2-60,  G3) 

Noncompliance  issues  that  cannot  be  resolved  within  the 
software  project  are  addressed  by  senior  management.  (L2- 
60,  G4) 

L2-PoIicy-6 
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Software  Configuration  Management  (SCM)  Poiicy 


SCM  policy 
checklist 


SCM  policy 
goals 


The  project  follows  a  written  organizational  policy  for  implementing  software 
configuration  management  (L2-72,  Cl).  This  policy  typically  specifies  that: 


Description 

References 

Responsibility  for  SCM  for  each  project  is  explicitly 
assigned.  (L2-72,  Cl,  1) 

SCM  is  implemented  throughout  the  project's  life  cycle. 
(L2-72,  Cl,  2) 

SCM  is  implemented  for  externally  deliverable  software 
products,  designated  internal  software  woric  products,  and 
designated  support  tools  used  inside  the  project  (e.g., 
compilers).  (L2-72,  Cl,  3) 

The  project£  establish  or  have  access  to  a  repository  for 
storing  configuration  items/units  and  the  associated  SCM 
records.  (L2-72,  Cl,  4) 

The  software  baselines  and  SCM  activities  are  audited  on  a 
periodic  basis.  (L2-73,  Cl,  5) 

Implementation  of  an  effective  software  configuration  management  policy  has  the 
following  results: 


Results  of  Effectively  Implementing  SCM  Policy 

References 

Software  configuration  management  activities  are  planned. 
(L2-72,  Gl) 

Selected  software  woric  products  are  identified,  controlled, 
and  available.  (L2-72,  G2) 

Changes  to  identified  software  work  products  are  controlled. 
(L2-72,  G3) 

Affected  groups  and  individuals  are  informed  of  the  status 
and  content  of  software  baselines.  (L2-72,  G4) 
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Level  2  Standards  Checklists 
Overview 


Introduction 


Definition 


Purpose 


What  the 
standards 
checklists  are 
not 


In  this  section 


This  section  describes  the  recommended  content  of  selected  work  products  in  the 
CMM  at  maturity  level  2. 


A  standard  checklist  describes  the  content  of  a  work  product  as  recommended  by 
the  CMM. 


The  purpose  of  the  standards  checklists  is  to  provide: 

•  Guidance  in  identifying  the  contents  of  standard  work  products  that  are 
recommended  by  the  CMM  at  level  2. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  standards  to 
determine  if  they  are  consistent  with  the  CMM  at  level  2. 

•  Information  that  can  be  used  to  develop  software  standards  that  are  consistent 
with  the  CMM  at  level  2. 


The  standards  checklists  contain  only  what  is  recommerded  by  the  CMM,  and  are 
not  complete  standards  in  themselves.  For  example,  the  standard  for  the  software 
development  plan  (SDP)  contains  only  content  recommended  by  the  CMM.  Other 
sources  for  the  content  of  a  SDP  should  also  be  considered,  such  as  ANSI/IEEE  Std 
1058.1-1987,  DOD-STD-2167,  DI-MCCR-80030,  etc. 


This  section  covers  the  following  standards: 


Standard 

KPA 

See  Page 

Allocated  requirements 

RM 

L2-Standards-2  J 

Statement  of  work 

SPP 

L2-Standards'3  j 

Software  development  plan 

SPP 

L2-Standards-4  I 

Contractual  agreement 

SSM 

L2-Standards-5 

Software  quality  assurance  plan 

SQA 

■■  ?-Standards-6 

Software  configuration  management  plan 

SCM 

L2-Standards-7 

t 

Note:  There  are  no  recommended  standards  for  the  software  project  tracking  and 
oversight  kpa. 
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Allocated  Requirements 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  allocated  requirements: 


~T 

Recommended  Content 

Nontechnical  requirements  (i.e.,  the  agreements,  conditions,  and/or 
contractual  terms)  that  affect  and  determine  the  activities  of  the  software 
project.  (L2-4,  Ab2,  1) 

Technical  requirements  for  the  software.  (L2-4,  Ab2,  2) 

Acceptance  criteria  that  will  be  used  to  validate  that  tlie  software  products 
satisfy  the  allocated  requirements.  (L2-4,  Ab2,  3) 

L2-Standards-2 
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Statement  of  Work 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  statement  of  work: 


Recommended  Content 

Scope  of  the  work.  (L2-14,  Abl,  1.1) 

Technical  goals  and  objectives.  (L2-14,  Abl,  1.2) 

Identification  of  customers  and  end  users.  (L2-14,  Abl,  1.3) 

Imposed  standards.  (L2-14,  Abl,  1.4) 

Assigned  responsibilities.  (L2-14,  Abl,  1.5) 

Cost  and  schedule  constraints  and  goals.  (L2-15,  Abl,  1.6) 

Dependencies  between  the  software  project  and  other  organizations.  (L2- 
15,  Abl,  1.7) 

Resource  constraints  and  goals.  (L2-15,  Abl,  1.8) 

Other  constraints  and  goals  for  development  and/or  maintenance.  (L2-15, 
Abl,  1.9) 

CMU/SEi-94-HB-1 


L2-Standards-3 


Software  Development  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  software  development  plan: 


~T 

Recommended  Content 

Software  project's  purpose,  scope,  goals,  and  objectives.  (L2-19,  A7, 1) 

Selection  of  a  software  life  cycle.  (L2-19,  A7,  2) 

Identification  of  the  selected  procedures,  methods,  and  standards  for 
developing  and/or  maintaining  the  software.  (L2-20,  A7,  3) 

Identification  of  software  work  products  to  be  developed.  (L2-20,  A7,  4) 

Size  estimates  of  the  software  woik  products  and  any  changes  to  the 
software  work  products.  (L2-20,  A7,  5) 

Estimates  of  the  software  project’s  effort  and  costs.  (L2-20,  A7,  6) 

Estimated  use  of  critical  computer  resources.  (L2-20,  A7,  7) 

Software  project  schedules,  including  identification  of  milestones  and 
reviews.  (1.2-20,  A7,  8) 

Idendftcation  and  assessment  of  the  project's  software  risks.  (L2-20,  A7,  9) 

Plans  for  the  project's  software  engineering  facilities  and  support  tools.  (L2- 
20,  A7,  10) 

L2-Standards*4 
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Contractual  Agreement 


Standard 

checklist 


The  following  table  contains  what  the  CMNl  describes  as  the  recommended  content 
of  the  contractual  agreement  between  the  prime  contractor  and  the  software 
subcontractor; 


Recommended  Content 

Terms  and  conditions.  (L2-50,  A3,  1) 

Statement  of  work.  (L2-50,  A3,  2) 

Requirements  for  the  products  to  be  developed.  (L2-50,  A3,  3) 

List  of  dependencies  between  the  subcontractor  and  the  prime  contractor. 
(L2-50,  A3,  4) 

Subcontracted  products  to  be  delivered  to  the  prime  contractor.  (L2-.50,  A3, 
5) 

Conditions  under  which  revisions  to  products  are  to  be  submitted.  (L2-50, 
A3,  6) 

Acceptance  procedures  and  acceptance  criteria  to  be  used  in  evaluating  the 
subcontracted  products  before  they  are  accepted  by  the  prime  contractor. 
(L2-50,  A3,  7) 

Procedures  and  evaluation  criteria  to  be  used  by  the  prime  contractor  to 
monitor  and  evaluate  the  subcontractor's  performance.  (L2-51,  A3,  8) 
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Software  Quality  Assurance  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  descnbes  as  the  recommended  content 
of  the  software  quality  assurance  plan: 


Recommended  Content 

Responsibilities  and  authority  of  the  SQA  group.  (L2-64,  A2,  1) 

Resource  requirements  for  the  SQA  group  (including  staff,  tools,  and 
facilities).  (L2-64,  A2,  2) 

Schedule  and  funding  of  the  project’s  SQA  group  activities.  (L2-64,  A2,  3) 

The  SQA  group's  participation  in  establishing  the  software  development 
plan,  standards,  and  procedures  for  the  project.  (L2-65,  A2,  4) 

Evaluations  to  be  performed  by  the  SQA  group.  (L2-65,  A2,  5) 

Audits  and  reviews  to  be  conducted  by  the  SQA  group.  (L2-65,  A2,  6) 

Project  standards  and  procedures  used  as  the  basis  for  the  SQA  group's 
reviews  and  audits.  (L2-65,  A2,  7) 

Procedures  for  documenting  and  tracking  noncompliance  issues  to  closure. 
(L2-65,  A2,  8) 

Documentation  that  the  SQA  group  is  required  to  produce.  (L2-65,  A2,  9) 

Method  and  frequency  of  providing  feedback  to  the  software  engineering 
group  and  other  software-related  groups  on  SQA  activities.  (L2-65,  A2,  10) 

L2-Standards-6 


CMU/SEI-94-HB-1 


Software  Configuration  Management  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  software  configuration  management  plan: 


Recommended  Content 

SCM  activities  to  be  performed,  the  schedule  of  activities,  the  assigned 
responsibilities,  and  the  resources  required  (including  staff,  tools,  and 
computer  facilities).  (L2-77,  A2,  1) 

SCM  requirements  and  activities  to  be  performed  by  the  software 
engineering  group  and  other  software-related  groups.  (L2-77,  A2,  2) 
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Level  2  Process  Checklists 
Overview 


Section  purpose 


In  this  section 


The  purpose  of  the  process  checklists  is  to  provide: 

•  Guidance  in  identifying  which  processes  are  required  by  the  CMM  at  level  2. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  processes  to 
determine  if  they  are  consistent  with  the  CMM  at  level  2. 

•  Information  that  can  be  used  to  develop  software  processes  that  are  consistent 
with  the  CMM  at  level  2. 


This  section  contains  checklists  for  the  following  key  process  areas: 


Key  Process  Area 

See  Page 

Requirements  Management 

L2-Process-3 

Software  Project  Planning 

L2-Process-23 

Software  Project  Tracking  &  Oversight 

L2-Process-59 

Software  Subcontract  Management 

L2-Process-97 

Software  Quality  Assurance 

L2-Process-129 

Software  Configuration  Management 

L2-Process-155 
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Requirements  Management  (RM)  Process 
RM  Process  -  Overview 


RM  process 
purpose 


RM  process 
description 


The  purpose  of  Requirements  Management  is  to  establish  a  common 
understanding  between  the  customer  and  the  software  project  of  the  customer's 
requiremeiits  that  will  be  addressed  by  the  software  project.  (L2-1) 


Requirements  Management  involves  establishing  and  maintaining  an  agreement 
with  the  customer  on  the  requirements  for  the  software  project.  'This  agreement  is 
referred  to  as  the  "system  requirements  allocated  to  the  software."  The  "customer" 
may  be  interpreted  as  the  system  engineering  group,  the  marketing  group,  another 
internal  organization,  or  an  external  customer.  The  agreement  covers  both  the 
technical  and  nontechnical  (e.g.,  delivery  dates)  requirements.  The  agreement 
forms  the  basis  for  estimating,  planning  performing,  and  tracking  the  software 
project's  activities  throughout  the  software  life  cycle. 

The  allocation  of  the  system  requirements  to  software,  hardware,  and  other  systeni 
components  (e.g.,  humans)  may  be  performed  by  a  group  external  to  the  software 
engineering  group  (e.g.,  the  system  engineering  group),  and  the  software 
engineering  group  may  have  no  direct  control  of  this  allocation.  Within  the 
constraints  of  the  project,  the  software  engineering  group  takes  appropriate  steps  to 
ensure  that  the  system  requirements  allocated  to  software,  which  they  are 
responsible  for  addressing,  are  documented  and  controlled. 

To  achieve  this  control,  the  software  engineering  group  reviews  the  initial  and 
revised  system  requirements  allocated  to  software  to  resolve  issues  before  they  are 
incorporated  into  the  software  project.  Whenever  the  system  requirements 
allocated  to  software  are  changed,  the  affected  software  plans,  work  products,  and 
activities  are  adjusted  to  remain  consistent  with  the  updated  requirements.  (L2-1) 


Continued  on  next  page 
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RM  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L2-Process-5 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L2-Process-8 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L2-Process-9 

Activities 

Description  of  the  activities  of  the 
process. 

L2-Process-10 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L2-Prccess-12 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L2-Process-13 

Reviews  and 

Audits 

List  of  reviews  and  audits. 

L2-Process-l6 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L2-Process-18 

Measurements 

Description  of  process  measurements. 

L2-Process-19 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L2-Process-20 

Training 

List  of  training. 

L2-Prooess-21 

Tools 

List  of  tools. 

L2-Process-22 

L2-Process-4 
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RM  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  panicipate  in  the 
requirements  management  process. 


Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

□  The  allocated  requirement:,  are 
reviewed  by:  (L2-3,  Cl,2) 

□  the  software  managers,  and 

□  other  affected  groups. 

□  Commitments  resulting  from  the 
allocated  requirements  are  negotiated 
with  the  affected  groups.  (L2-6,  Al,  4) 

□  Changes  to  commitments  within  the 
organization  are  negotiated  with  the 
affected  groups.  (L2-7,  A3,  1 .2) 

□  Changes  that  need  to  be  made  to  the 
software  plans,  work  products,  and 
activities  resulting  from  changes  to  the 
allocated  requirements  are:  (L2-8,  A3, 
2) 

□  identified, 

□  evaluated, 

□  assessed  for  risk, 

□  documented, 

□  planned, 

□  communicated  to  the  affected 
groups  and  individuals,  and 

□  tracked  to  completion. 

□  Changes  to  commitments  resulting 
from  changes  to  the  allocated 
requirements  are  negotiated  with  the 
affected  groups.  (L2-10,  V3,  3) 

Continued  on  next  page 
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RM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
requirements  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference  j 

(Affected) 

individuals 

□  Individuals  who  have  experience  and 
expertise  in  the  application  domain  and 
in  software  engineering  are  assigned  to 
manage  the  allocated  requirements. 
(L2-5,  Ab3.  1) 

□  Changes  that  need  to  be  made  to  the 
software  plans,  work  products,  and 
activities  resulting  from  changes  to  the 
allocated  requirements  are:  (L2-8,  A3, 
2) 

□  identified, 

□  evaluated, 

□  assessed  for  risk, 

□  documented, 

□  planned, 

□  communicated  to  the  affected 
groups  and  individuals,  and 

□  tracked  to  completion. 

Group 

responsible  for 
analyzing  and 
allocating 
system 
requirements 

Any  allocated  requirements  identified  as 
having  potential  problems  are  reviewed 
with  the  group  responsible  for  analyzing 
and  allocating  system  requirements,  and 
necessary  changes  are  made.  (L2-6,  Al,  3) 

Individuals 
and  groups 
external  to  the 
organization 

Changes  to  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management.  (L2-7,  A3,  1 .1) 

Project 

manager 

The  activities  for  managing  the  allocated 
requirements  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L2-9,  V2) 

Continued  on  next  page 
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RM  Process  -  Roles,  continued 


Roles,  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

continued  requirements  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Senior 

management 

□  Changes  to  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management.  (L2-7,  A3,  1.1) 

□  The  activities  for  managing  the 
allocated  requirements  are  reviewed 
with  senior  management  on  a  periodic 
basis.  (L2-9,  VI) 

Software 

engineering 

group 

□  Members  of  the  software  engineering 
group  and  other  software-related 
groups  are  trained  to  perform  their 
requirements  management  activities. 
(L2-5,  Ab4) 

□  The  software  engineering  group 
reviews  the  allocated  requirements 
before  they  are  incorporated  into  the 
software  project.  (L2-5,  Al) 

□  The  software  engineering  group  uses 
the  allocated  requirements  as  the  basis 
for  software  plans,  work  products,  and 
activities.  (L2-6,  A2) 

□  The  allocated  requirements  are 
reviewed,  and  problems  are  resolved 
before  the  software  engineering  group 
commits  to  them.  (L2-10,  V3,  1) 

Software 

manager 

The  allocated  requirements  are  reviewed 
by:  (L2-3,  Cl,2) 

□  the  software  managers,  and 

□  other  affected  groups. 

Software- 
related  groups 

Members  of  the  software  engineering 
group  and  other  software-related  groups 
are  trained  to  perform  their  requirements 
management  activities.  (L2-5,  Ab4) 

SQA  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  managing  the  allocated 
requirements  and  reports  results.  (L2-9, 

V3) 
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RM  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  slates  described  in  the  table  below 
before  entering  the  requirements  management  process. 


Input 

State 

References 

Allocated 

requirements 

are  documented.  (L2-3,  Cl,  1) 

1 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  requirements  management  process. 


Condition 

References 

The  project  follows  a  written  organizational  policy  for 
managing  the  system  requirements  allocated  to  software. 
(L2-2,  Cl) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  RM  policy.] 

For  each  project,  responsibility  is  established  for  analyzing 
the  system  requirements  and  allocating  them  to  hardware, 
software,  and  other  system  components.  (L2-3,  Abl) 

This  responsibility  covers: 

□  Managing  and  documenting  the  system  requirements 
and  their  allocation  throughout  the  project's  life. 

□  Effecting  changes  to  the  system  requirements  and  their 
allocation. 

Adequate  resources  and  funding  are  provided  for  managing 
the  allocated  requirements.  (L2-5,  Ab3) 

Individuals  who  have  experience  and  expertise  in  the 
application  domain  and  in  software  engineering  are  assigned 
to  manage  the  allocated  requirements.  (L2-5,  Ab3,  1) 

Tools  to  support  the  activities  for  managing  requirements 
are  made  available.  (L2-5,  Ab3,  2) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  are  trained  to  ;  erform  their 
requirements  management  activities.  (L2-5,  Ab4) 
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RM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  requirements  management 
process. 


Input 

Org.  Input 

References 

Allocated  requirements.  (L2-2,  Cl) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  allocated 
requirements.] 

Changes  to  the  allocated  requirements. 
(L2-4,  Abl,  2) 

Changes  to  the  system  requirements.  (L2- 
4.  Abl,  2) 

Existing  commitments.  (L2-7,  A3,  1) 

.. 

Software  activities.  (L2-3,  Cl,3) 

Software  plans.  (L2-3,  Cl,3) 

Software  work  products.  (L2-3,  Cl,  3) 

System  requirements.  (L2-3,  Abl) 
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RM  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  requirements  management 
process. 


Activities 

References 

The  software  engineering  group  reviews  allocated 
requirements  before  they  are  incorporated  into  the  software 
project.  (L2-5,  Al) 

[Refer  to  RM  Process  Reviews  ard  Audits  for  additional 
information.] 

Commitments  resulting  from  the  allocated  requirements  are 
negotiated  with  the  affected  groups.  (L2-6,  A  1,4) 

The  software  engineering  group  uses  the  allocated 
requirements  as  the  basis  for  software  plans,  work  products, 
and  activities.  (L2-6,  A2) 

Changes  to  the  allocated  requirements  are  reviewed  and 
incorporated  into  the  software  project.  (L2-7,  A3) 

□  The  impact  to  existing  commitments  is  assessed  and 
changes  are  negotiated  as  appropriate. 

□  Changes  to  commitments  made  to  individuals  and 
groups  external  to  the  organization  are  reviewed 
with  senior  management. 

□  Changes  to  commitments  within  the  organization  are 
negotiated  with  the  affected  groups. 

□  Changes  that  need  to  be  made  to  the  software  plans, 
work  products,  and  activities  resulting  from  changes  to 
the  allocated  requirements  are: 

□  identified, 

□  evaluated, 

□  assessed  for  risk, 

□  documented, 

□  planned, 

□  communicated  to  the  affected  groups  and 
individuals,  and 

□  tracked  to  completion. 

Measurements  are  made  and  used  to  determine  the  status  of 
the  activities  for  managing  the  allocated  requirements.  (L2- 
8,  Ml) 

The  activities  for  managing  requirements  are  reviewed  with 
senior  management  on  a  periodic  basis.  (L2-9,  VI) 

Continued  on  next  page 
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RM  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  requirements  management 
process,  continued  from  the  previous  page. 


Activities 

References 

The  activities  for  managing  the  allocated  requirements  are 
reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-9,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  managing  the  allocated 
requirements  and  reports  the  results.  (L2-9,  V3) 

[Refer  to  RM  Process  Reviews  and  Audits  for  additional 
information.] 
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RM  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  requirements 
management  process. 


Output 

Org,  Output 

References 

Allocated  requirements.  (L2-5,  Al) 

Changes  that  need  to  be  made  to  the 
software  plans,  work  products,  and  activities 
resulting  from  changes  to  the  allocated 
requirements.  (L2-8,  A3,  2) 

Changes  to  allocated  requirements.  (L2-7, 
A3) 

Changes  to  commitments  made  to 
individuals  and  groups  external  to  the 
organization.  (L2-7,  A3,  1.1) 

Changes  to  commitments  within  the 
organization.  (L2-7,  A3,  1.2) 

_ 1 

Commitments  resulting  from  the  allocated 
requirements.  (L2-6,  Al,  4) 

Impact  to  existing  commitments.  (L2-7, 

A3,  1) 

Measurements.  (L2-8,  Ml) 

Software  activities.  (L2-10,  V3,  2) 

Software  plans.  (L2-10,  V3,  2) 

Software  requirements.  (L2-7,  A2,  3) 

Software  work  products.  (L2-10,  V3,  2) 
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RM  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  requirements  management  process. 


Output 

State 

References 

Allocated 

requirements 

□  are  documented.  (L2-3,  Cl,  1) 

□  are  reviewed  by:  (L2-3,  Cl,2) 

U  the  software  managers,  and 

□  other  aflTected  groups. 

□  (that  are  incomplete  and  missing) 
are  identified.  (L2-5,  Al,  1) 

□  are  reviewed  to  determine 
whether  they  are:  (L2-6,  Al,  2) 

□  feasible  and  appropriate  to 
implement  in  software, 

□  clearly  and  properly  stated, 

□  consistent  with  each  other, 
and 

□  testable. 

□  identified  as  having  potential 
problems  are  reviewed  with  the 
group  responsible  for  analyzing 
and  allocating  system 
requirements,  and  necessary 
changes  are  made.  (L2-6,  Al,  3) 

□  are  managed  and  controlled. 
(L2-7,  A2,  1) 

□  are  the  basis  for  the  software 
development  plan.  (L2-7,  A2,  2) 

□  are  the  basis  for  developing  the 
software  requirements.  (L2-7, 

A2,  3) 

□  are  reviewed,  and  problems  are 
resolved  before  the  software 
engineering  group  commits  to 
them.  (L2-10,  V3,  1) 

Changes  to  allocated 
requirements 

□  are  reviewed.  (L2-  7,  A3) 

□  are  incoiporated  into  the 
software  project.  (L2-7,  A3) 

1 

_ _ I 

Continued  on  next  page 
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RM  Process  -  Exit  Criteria,  continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  requirements  management  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Changes  to 
commitments 
resulting  from 
changes  to  the 
allocated 
requirements 

are  negotiated  with  the  affected 
groups.  (L2-10,  V3,  3) 

Changes  to 
commitments  made 
to  individuals  and 
groups  external  to 
the  organization 

are  reviewed  with  senior 
management.  (L2-7,  A3,  1.1) 

Changes  to 
commitments  within 
the  organization 

are  negotiated  with  the  aflfected 
groups.  (L2-7,  A3,  1 .2) 

Changes  that  need  to 
be  made  to  the 
software  plans,  work 
products,  and 
activities  resulting 
from  changes  to  the 
allocated 
requirements 

are:  (L2-8,  A3,  2) 

□  identified, 

□  evaluated, 

□  assessed  for  risk, 

□  documented, 

□  planned, 

□  communicated  to  the  affected 
groups  and  individuals,  and 

□  tracked  to  completion. 

Commitments 
resulting  from  the 
allocated 
requirements 

are  negotiated  with  the  affected 
groups.  (L2-6,  Al,4) 

Impact  to  existing 
commitments 
(resulting  from 
changes  to  the 
allocated 
requirements) 

is  assessed.  (L2-7,  A3,  1) 

L 

Measurements  (to 
determine  the  status 
of  the  activities  for 
managing  the 
allocated 
requirements) 

□  are  made.  (L2-8,  Ml) 

□  are  used.  (L2-8,  Ml) 

Continued  on  next  page 
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RM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  requirements  management  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Software  plans 

□  are  changed  to  be  consistent  with 
changes  to  the  allocated 
requirements.  (L2-3,  Cl,  3) 

□  are  appropriately  revised  when 
the  allocated  requirements 
change.  {L2-10,  V3,  2) 

Software  work 
products 

□  are  changed  to  be  consistent  with 
changes  to  the  allocated 
requirements.  (L2-3,  Cl,  3) 

□  are  appropriately  revised  when 
the  allocated  requirements 
change.  (L2-10,  V3,  2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  requirement  management  process. 


Condition 

References 

The  activities  for  managing  the  allocated  requirements  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L2- 
9,  VI) 

The  activities  for  managing  the  allocated  requirements  are 
reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-9,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  managing  the  allocated 
requirements  and  reports  the  results.  (L2-9,  V3) 

The  allocated  requirements  are  reviewed,  and  problems  are 
resolved  before  the  software  engineering  group  commits  to 
them.  (L2-10,  V3,  1) 
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RM  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  requirements 
management  process. 


Review  or  Audit 

Review 

Participants 

References 

Allocated  requirements  are  reviewed  by: 
(L2-3,C1,2) 

□  the  software  managers,  and 

□  other  affected  groups. 

Software 

managers 

Affected 

groups 

The  software  engineering  group  reviews 
allocated  requirements  before  they  are 
incorporated  into  the  software  project. 

(L2-5,  Al) 

□  Incomplete  and  missing  allocated 
requirements  are  identified. 

□  The  allocated  requirements  are 
reviewed  to  determine  whether  they 
are: 

□  feasible  and  appropriate  to 
implement  in  software, 

□  clearly  and  properly  stated, 

□  consistent  with  each  other,  and 

□  testable. 

□  Any  allocated  requirements  identified 
as  having  potential  problems  are 
reviewed  with  the  group  responsible 
for  analyzing  and  allocating  system 
requirements,  and  necessary  changes 
are  made. 

Software 

engineering 

group 

Group 

responsible  for 
analyzing  and 
allocating 
system 
requirements 

Changes  to  the  allocated  requirements  are 
reviewed  and  incorporated  into  the 
software  project.  (L2-7,  A3) 

Not  specified  in 
CMM 

Changes  to  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management.  (L2-7,  A3,  1.1) 

Senior 

management 

Continued  on  next  page 
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RM  Process  -  Reviews  and  Audits,  continued 


Reviews  and  The  table  below  lists  the  recommended  reviews  and  audits  for  the  requirements 
audits,  management  process,  continued  from  the  previous  page. 

continued 


V 

Review  or  Audit 

Review 

Participants 

References 

The  activities  for  managing  requirements 
are  reviewed  with  senior  management  on  a 
periodic  basis.  (L2-9,  VI) 

Senior 

management 

The  activities  for  managing  the  allocated 
requirements  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L2-9,  V2) 

Project 

manager 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  managing  the  allocated 
requirements  and  reports  the  results.  (L2- 
9,  V3) 

SQA  group 

At  a  minimum,  these  reviews  and/or  audits 
verify  that: 

□  The  allocated  requirements  are 
reviewed,  and  problems  are  resolved 
before  the  software  engineering  group 
commits  to  them. 

Software 

engineering 

group 

□  The  software  plans,  work  products,  and 
activities  are  appropriately  revised 
when  the  allocated  requirements 
change. 

□  Changes  to  commitments  resulting 
from  changes  to  the  allocated 
requirements  are  negotiated  with  the 
affected  groups. 

Affected 

groups 
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RM  Process  •  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  requirements  management  process. 


V 

Work  Products  Managed  and  Controlled 

References 

Allocated  requirements.  (L2-7,  A2,  1) 

L2-Process-18 
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RM  Process  -  Measurements 
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RM  Process  -  Documented  Procedures 


Documented 

procedures 


The  CMM  does  not  recommend  that  any  activities  be  performed  according  to  a 
documented  procedure  for  the  requirements  management  process. 


L2-Process-20 


CMU/SEI-94-HB-1 


RM  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  requirements  management 
process. 


Training 

References 

Members  of  the  software  engineering  group  and  other 
software-related  groups  are  trained  to  perform  their 
requirements  management  activities.  (L2-5,  Ab4) 
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RM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  requirements  management 
process. 


V 

Tools 

References 

Tools  to  support  the  activities  for  managing  requirements. 
(L2-5,  Ab3,  2) 

Examples  of  support  tools  include; 

□  spreadsheet  programs, 

□  tools  for  configuration  management, 

□  tools  for  traceability,  and 

□  tools  for  test  management. 

L2-Proccss-2?. 
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Software  Project  Planning  (SPP)  Process 
SPP  Process  -  Overview 


SPP  process 
purpose 


SPP  process 
description 


The  purpose  of  Software  Project  Planning  is  to  establish  reasonable  plans  for 
performing  the  software  engineering  and  for  managing  the  software  project. 
(L2-11) 


Software  Project  Planning  involves  developing  estimates  for  the  work  to  be 
performed,  establishing  the  necessary  commitments,  and  defining  the  plan  to 
perform  the  work. 

The  software  planning  begins  with  a  statement  of  the  work  to  be  performed  and 
other  constraints  and  goats  that  define  and  bound  the  software  project  (those 
established  by  the  practices  of  the  Requirements  Management  key  process  area). 
The  software  planning  process  includes  steps  to  estimate  the  size  of  the  software 
work  products  and  the  resources  needed,  produce  a  schedule,  identify  and  assess 
software  risks,  and  negotiate  commitments.  Iterating  through  these  steps  may  be 
necessary  to  establish  the  plan  for  the  software  project  (i.e.,  the  software 
development  plan). 

This  plati  provides  the  basis  for  performing  and  managing  the  software  project’s 
activities  and  addresses  the  commitments  to  the  software  project's  customer 
according  to  the  resources,  constraints,  and  capabilities  of  the  software  project. 
(L2-11) 


Continued  on  next  page 
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SPP  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L2-Process-25 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L2-Process-34 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L2-Process-36 

Activities 

Description  of  the  activities  of  the 
process. 

L2-Process-37 

Outputs 

Description  of  iiie  work  products 
produced  by  the  process. 

L2-Process-40 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L2-Process-42 

Reviews  and 

Audits 

List  of  reviews  and  audits. 

L2-Process-50 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L2-Process-53 

Measurements 

Description  of  process  measurements. 

L2-Process-54 

Documented 

Procedures 

List  of  the  activities  ‘o  be  completed 
according  to  a  documented  procedure. 

L2-Process-55 

Training 

List  of  training. 

L2-Process-56 

Tools 

List  of  tools. 

L2-Process-57 

L2-Process-24 
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SPP  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

□  Affected  groups  review  the  software 
project's:  (L2-13,  C2,  4) 

□  software  size  estimates, 

□  effort  and  cost  estimates, 

□  schedules,  and 

□  other  commitments. 

□  The  statement  of  work  is  reviewed  by: 
(L2-15,  Abl,  2) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  Th-  software  engineering  group 
participates  with  other  affected  groups 
in  the  overall  project  planning 
throughout  the  project's  life.  fL2-17, 
A3) 

□  The  software  development  plan  is 
reviewed  by:  (L2-19,  A6,  4) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  The  plans  for  the  project’s  software 
engi.neering  facilities  and  support  tools 
are  reviewed  by  all  affected  groups. 
(L2-25,  A 14,  3) 

□  A  summary  report  from  each  review 
with  senior  management  is  prepared 
and  distributed  to  the  affected  groups 
and  individuals.  (L2-26,  V],5) 

Role  continues  on  the  next  page 

Continued  on  next  page 
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SPP  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups, 

continued 

□  The  activities  for  software  project 
planning  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L2-26,  V2) 

□  Affected  groups  are  represented. 

□  A  summary  report  from  each  review 
with  the  project  manager  is  prepared 
and  distributed  to  the  affected  groups 
and  individuals.  (L2-27,  V2,  7) 

i 

Affected 

individuals 

□  A  summary  report  from  each  review 
with  senior  management  is  prepared 
and  distributed  to  the  affected  groups 
and  individuals.  (L2-26,  VI,  5) 

□  A  summary  report  from  each  review 
with  the  project  manager  is  prepared 
and  distributed  to  the  affected  groups 
and  individuals.  (L2-27.  V2,  7) 

Engineering 

groups 

□  Involvement  of  other  engineering 
groups  in  the  software  activities  is 
negotiated  with  these  groups  and  is 
documented.  (L2-13,  C2,  3) 

□  Plans  for  software-related  groups  and 
other  engineering  groups  involved  in 
the  activities  of  the  software 
engineering  group  are  negotiated  with 
those  groups,  the  support  efforts  are 
budgeted,  and  trie  agreements  are 
documented  (L2-18,  A6,  2) 

□  Plans  for  involvement  of  the  software 
engineering  group  in  the  activities  of 
other  software-related  groups  and  other 
engineering  groups  are  negotiated  with 
those  groups,  the  support  efforts  are 
budgeted,  and  the  agreements  are 
documented.  (L2-19,  A6,  3) 

_  J 

Conti’uicJ  on  next  page 
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SPP  Process  -  Roles,  Continued 


Roles, 

continued 


Th>.  able  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Individuals 

□  Where,  feasible,  experienced 
individuals,  who  have  expertise  in  the 
application  domain  of  the  software 
project  being  planned,  are  available  to 
develop  the  software  development  plan. 
(L2-16,.Ab3,  1) 

□  The  software  managers,  software 
engineers,  and  other  individuals 
involved  in  the  software  project 
planning  are  trained  in  the  software 
estimating  and  planning  procedures 
applicable  to  their  areas  of 
responsibility.  {L2-16,  Ab4) 

Individuals 
and  groups 
external  to  the 
organization 

□  Senior  management  reviews  all  software 
project  commitments  made  to 

individuals  and  groups  external  to  the 
organization.  (L2-13,  C2,  5) 

□  Software  project  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management  according  to  a 
documented  procedure.  (L2-17,  A4) 

Continued  on  next  page 
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SPP  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Project 

manager 

□  The  software  project's  commitments  are 
negotiated  between:  (L2-12,  C2,  2) 

□  the  project  manager, 

□  the  prciject  software  manager,  and 

□  the  other  software  managers. 

□  The  statement  of  work  is  reviewed  by: 
(L2-15,  Abl,  2) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  The  software  development  plan  is 
reviewed  by:  (L2-19,  A6,  4) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  The  activities  for  software  project 
planning  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L2-26,  V2) 

Continued  on  next  page 
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SPP  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Project 

software 

manager 

□  A  project  software  manager  is 
designated  to  be  responsible  for 
negotiating  commitments  and 
developing  the  project's  software 
development  plan.  (L2-12,  Cl) 

□  The  software  project's  commitments  are 
negotiated  between;  (L2-12,  C2,  2) 

□  the  project  manager, 

□  the  project  software  manager,  and 

□  the  other  software  managers. 

□  The  statement  of  vvork  is  reviewed  by: 
(L2-15,  Abl,  2) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  The  project  software  manager,  directly 
or  by  delegation,  coordinates  the 
project's  software  planning.  (L2-15, 
Ab2,  1) 

□  The  software  development  plan  is 
reviewed  by;  (L2-19,  A6,  4) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

Continued  on  next  page 
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SPP  Process  -  Roles,  Conlinued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Senior 

management 

□  Senior  management  reviews  all 
software  project  commitments  made  to 
individuals  and  groups  external  to  the 
organization.  (L2-13,  C2,  5) 

□  Software  project  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management  according  to  a 
documented  procedure.  (L2-17,  A4) 

□  The  activities  for  software  project 
planning  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2- 
26,  VI) 

i 

Software 

engineering 

group 

□  The  software  engineering  group 
participates  on  the  project  proposal 
team.  (L2-16,  Al) 

□  The  software  engineering  group  is 
involved  in:  (L2-17,  AI,  I) 

□  proposal  preparation  and 
.submission, 

□  clarification  discussions  and 
submissions,  and 

□  negotiations  of  c..  .iges  to 
commitments  that  affect  the 
softv./are  project. 

□  The  software  engineering  group 
reviev/s  the  project's  proposed 
commitments.  (L2-17,  Al,  2) 

Roie  continues  on  the  next  page 
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SPP  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 

engineering 

group, 

continued 

□  The  software  engineering  group 
participates  with  other  affected  groups 
in  the  overall  project  planning 
throughout  the  project's  life.  (L2-17, 
A3) 

□  The  software  engineering  group 
reviews  the  project-level  plans.  (L2-17, 
A3,  1) 

□  Plans  for  software-related  groups  and 
other  engineering  groups  involved  in 
the  activities  of  the  software 
engineering  group  are  negotiated  with 
those  groups,  the  support  efforts  are 
budgeted,  and  the  agreements  are 
documented,  (L2-18,  A6,  2) 

□  Plans  for  involvement  of  the  software 
engineering  group  in  the  activities  of 
other  software-related  groups  and  other 
engineering  groups  are  negotiated  with 
those  groups,  the  support  efforts  are 
budgeted,  and  the  agreements  are 
documented.  (L2-19,  A6,  3) 

Software 

engineers 

The  software  managers,  software  engineers, 
and  other  individuals  involved  in  the 
software  project  planning  are  trained  in 
software  estimating  and  planning 
procedures  applicable  to  their  areas  of 
responsibility.  (L2-16,  Ab4) 

Continued  on  next  page 
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SPP  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  planning  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 

manager 

□  The  software  project  s  commitments  are 
negotiated  between:  (L2-12,  Cl,  2) 

□  the  project  manager, 

□  the  project  software  manager,  and 

□  the  other  software  managers. 

□  The  statement  of  work  is  reviewed  by: 
(L2-15,  Abl,  2) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  Responsibilities  for  the  software  work 
products  and  activities  are  partitioned 
and  assigned  to  software  managers  in 
a  traceable,  accountable  manner.  (L2- 
15,  Ab2,  2) 

□  The  software  managers,  software 
engineers,  and  other  individuals 
involved  in  the  software  project 
planning  are  trained  in  software 
estimating  and  planning  procedures 
applicable  to  their  areas  of 
responsibility.  (L2-16,  Ab4) 

□  The  software  development  plan  is 
reviewed  by:  (L2-19,  A6,  4) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

Continued  on  next  page 
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SPP  Process  -  Roles,  Continued 


Roles,  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

continued  software  project  planning  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software- 
related  groups 

□  Plans  for  software-related  groups  and 
other  engineering  groups  involved  in 
the  activities  of  the  software 
engineering  group  are  negotiated  with 
those  groups,  the  support  efforts  are 
budgeted,  and  the  agreements  are 
documented.  (L2-18,  A6,  2) 

□  Plans  for  involvement  of  the  software 
engineering  group  in  the  activities  of 
other  software-related  “roups  and 
other  engineering  groups  are 
negotiated  with  those  groups,  the 
support  efforts  are  budgeted,  and  the 
agreements  are  documented.  (L2-19, 
A6,  3) 

SQA  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  project  planning  and 
reports  the  results.  (L2-27,  V3) 
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SPP  Process  -  Entry  Criteria 


Input-b^ed  The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 

entry  criteria  before  entering  the  software  project  planning  process. 


Input 

State 

References 

Cost  data 

□  are  from  the  organization’s 
projects  when  possible.  (L2-22, 
AlO,  2.1) 

□  take  into  accouni  the  effort  and 
significant  costs  that  go  into 
making  the  software  work 
products.  (L2-22,  AlO,  2.2) 

Historical  data 

are  used  where  available.  (L2-21, 

A9,  3) 

Productivity  data 

□  are  from  the  organization’s 
projects  when  possible.  (L2-22, 
AlO,  2.1) 

□  take  into  account  the  effort  and 
significant  costs  that  go  into 
making  the  software  work 
products.  (L2-22,  AlO,  2.2) 

.Statement  of  work 

□  is  documented.  (L2-14,  Abl) 

□  is  approved.  (L2-14,  Abl) 

□  exists  for  the  software  project. 
(L2-14,  Abl) 

□  is  reviewed  by:  fL2-15,  Abl,  2) 

□  the  projec  .lanager, 

□  the  project  software 
manager, 

□  the  other  software  managers, 
and 

□  other  affected  groups. 

□  is  managed  and  controlled.  (L2- 
15,  Abl,  3) 
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SPP  Process  -  Entry  Criteria,  Continued 


General  entry 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  project  planning  process. 


V 

Condition 

References 

A  project  software  manager  is  designated  to  be  responsible 
for  negotiating  commitments  and  developing  the  project’s 
software  development  plan.  (L2-12,  Cl) 

The  project  follows  a  written  organizational  policy  for 
planning  a  software  project.  (L2^-12,  C2) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  SPP  policy.] 

Responsibilities  for  developing  the  software  development 
plan  are  assigned.  (L2-I5,  Ab2) 

Responsibilities  for  the  software  work  products  and  activities 
are  partitioned  and  assigned  to  software  managers  in  a 
traceable,  accountable  manner.  (L2-15,  Ab2,  2) 

Adequate  resources  and  funding  are  provided  for  planning 
the  software  project.  (L2-16,  Ab3) 

I 

Where  feasible,  experienced  individuals  who  have  expertise 
in  the  application  domain  of  the  software  project  being 
planned  are  available  to  develop  the  software  development 
plan.  (L2-16,  Ab3,  I) 

Tools  to  support  the  software  project  planning  activities  are 
made  available.  (L2-16,  Ab3,  2) 

The  software  managers,  software  engineers,  and  other 
individuals  involved  in  the  software  project  planning  are 
trained  in  the  software  estimating  and  planning  procedures 
applicable  to  their  areas  of  responsibility.  (L2-16,  Ab4) 

Software  project  planning  is  initiated  in  the  early  stages  of, 
and  in  parallel  with,  the  overall  project  planning.  (L2-17, 

A2) 
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SPP  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  project  planning 
process. 


Input 

Org.  Input 

References 

Allocated  requirements.  (L2-18,  A6,  1.4) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  allocated 
requirements.] 

Cost  data.  (L2-22,  AlO,  2.1) 

Customer's  standards.  (L2-18,  A6,  1.1) 

Historical  data  (where  available).  (L2-21, 
A9,  3) 

Productivity  data  (historical  and/or 
current).  (L2-22,  AlO,  2) 

Project  proposal.  (L2-16,  Al) 

Project's  standards.  (L2-18,  A6,  1.2) 

Proposed  commitments.  (L2-I7,  Al,  2) 

Statement  of  work.  (L2-14,  Abl) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  a  statement  of 
work.] 
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SPP  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  software  project  planning 
process. 


V 

Activities 

References 

The  software  engineering  group  participates  on  the  project 
proposal  team.  (L2-16,  Al) 

□  The  software  engineering  group  is  involved  in:  (L2-17, 
Al,  1) 

□  proposal  preparation  and  submission, 

□  clarification  discussions  and  submissions,  and 

□  negotiations  of  changes  to  commitments  that  affect 
the  software  project.. 

□  The  software  engineering  group  reviews  the  project's 
proposed  commitments.  (L2-17,  Al,  2) 

The  software  engineering  group  reviews  the  project-level 
plans.  (L2-17,  A3,  1) 

Software  project  commitments  made  to  individuals  and 
groups  external  to  the  organization  are  reviewed  with 
senior  management  according  to  a  documented  procedure. 
(L2-17,  A4) 

A  software  life  cycle  with  predefined  stages  of  manageable 
size  is  identified  or  defined.  (L2-17,  A5) 

The  project's  software  development  plan  is  developed 
according  to  a  documented  procedure.  (L2-18,  A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  plan  for  the  software  project  is  documented.  (L2-19, 

A7) 

Software  work  products  that  are  needed  to  establish  and 
maintain  control  of  the  software  project  are  identified.  (L2- 
20,  A8) 

Estimates  for  the  size  of  the  software  work  products  (or 
changes  to  the  size  of  software  work  products)  are  derived 
according  to  a  documented  procedure.  (L2-2i,  A9) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Estimates  for  the  software  project's  effort  and  costs  are 
derived  according  to  a  documented  procedure.  (L2-22, 

AlO) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Continued  on  next  page 
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SPP  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  project  planning 
process,  continued  from  the  previous  page. 


Activities 

References 

Estimates  for  critical  computer  resources  are  derived 
according  to  a  documented  procedure.  (L2-23,  All) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  project's  software  schedule  is  derived  according  to  a 
documented  procedure.  (L2-23,  A12) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  software  risks  associated  with  the  cost,  resource, 
schedule,  and  technical  aspects  of  the  project  are  identified, 
assessed,  and  documented.  (L2-24,  A13) 

□  The  risks  are  analyzed  and  prioritized  based  on  their 
potential  impact  to  the  project. 

□  Contingencies  for  the  risks  are  identified. 

Plans  for  the  project's  software  engineering  facilities  and 
support  tools  are  prepared.  (L2-25,  A 14) 

□  Responsibilities  are  assigned  and  commitments  are 
negotiated  to  procure  or  develop  these  facilities  and 
support  tools.  (L2-25,  A14,  2) 

□  The  plans  are  reviewed  by  all  aH'ected  groups.  (L2-25, 
A14,  3) 

Software  planning  data  are  recorded.  (L2-25,  A15) 

□  Information  recorded  includes  the  estimates  and  the 
associated  information  needed  to  reconstruct  the 
estimates  and  assess  their  reasonableness.  (L2-25,  A 15, 

1) 

Measurements  are  made  and  used  to  determine  the  status  of 
the  software  planning  activities.  (L2-25,  Ml) 

The  activities  for  software  project  planning  are  reviewed  with 
senior  management  on  a  periodic  basis.  (L2-26,  VI) 

[Refer  to  SPP  Process  Reviews  and  Audits  for  additional 
information.] 

Continued  on  next  page 
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SPP  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  project  planning 
process  continued  from  the  previous  page. 


Activities 

References 

I 

The  activities  for  software  project  planning  are  reviewed  with 
the  project  manager  on  both  a  periodic  and  event-driven 
basis.  (L2-26,  V2) 

[Refer  to  SPP  Process  Reviews  and  Audits  for  additional 
information.] 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  planning  and 
reports  the  results.  (L2-27,  V3) 

[Refer  to  SPP  Process  Reviews  and  Audits  for  additional 
information.] 
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SPP  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  project 
planning  process. 


V 

Output 

Org.  Outputs 

References 

Action  items  resulting  from  reviews  with 
senior  management.  (L2-26.  VI,  4) 

Action  items  resulting  from  reviews  with 
the  project  manager.  {L2-27,  V2,  6) 

Assumptions  made  in  deriving  the 
estimates  for  the  software  project’s  effort 
and  costs.  (L2-23,  AIO,  4) 

Assumptions  made  in  deriving  the  project’s 
software  schedule.  (L2-24,  A12,  5) 

Contingencies  for  the  risks  associated  with 
i.ie  cost,  resource,  schedule,  and  technical 
aspects  of  the  project.  (L2-24,  A13,  2) 

Distributions  of  effort,  staffing,  and  cost 
estimates  over  the  software  life  cycle.  (L2- 
23.  A!0,  3.3) 

Estimates  for  the  project’s  critical  computer 
resources.  (L2-23,  All) 

Estimates  for  the  size  of  the  software  work 
products  (or  changes  to  the  size  of  software 
work  products).  (L2-2!,  A9) 

Estimates  for  the  software  project's  effort 
and  costs.  (L2-22,  AIO) 

Estimates  of  capacity  requirements  for  the 
project's  software  engineering  facilities  and 
support  tools.  (L2-25,  AI4,  1) 

Estimates  of  the  critical  computer  resources 
for  the  project.  tL2-23,  All,  3) 

Measurements  to  determine  the  status  of 
the  software  planning  activities.  (L2-25, 
Ml) 

Plans  for  involvement  of  the  software 
engineering  group  in  the  activities  of  other 
software-related  groups  and  other 
engineering  groups.  (L2-19,  A6,  3) 

Flans  for  software-related  groups  and 
other  engineering  groups  involved  in  the 
activities  of  the  software  engineering 
group.  (L2-18,  A6,  2) 

Conthued  on  next  page 
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SPP  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  project 
planning  process,  continued  from  the  previous  page. 


Output 

Org.  Outputs 

References 

Plans  for  the  project's  software  engineering 
facilities  and  support  tools.  (L2-25,  AM) 

Project's  software  development  plan.  (L2- 
15,  Ab2) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  the  software 
development  plan.] 

Project's  software  schedule.  (L2-23,  A12) 

Size  estimating  assumptions.  (L2-21,  A9, 

4) 

Software  life  cycle.  (L2-17,  A5) 

Software  planning  data.  (L2-25,  A 15) 

Software  project  commitments.  (L2-17, 

A4) 

Software  risks  associated  with  the  cost, 
resource,  schedule,  and  technical  aspects  of 
the  project.  (L2-24,  A 13) 

Software  work  products  that  are  needed  to 
establish  and  maintain  control  of  the 
software  project.  (L2-20,  A8) 

Sources  and  rationale  for  productivity  data 
used  for  estimating  the  software  project's 
effort  and  costs.  vL2-22,  AlO,  2) 

Summary  report  from  each  review  with 
senior  management.  (L2-26,  Vl,5) 

Summary  report  from  each  review  with  the 
project  manager.  (L2-27,  V2,  7) 

_ 1 

Time  phasing  of  activities.  (L2-22,  AlO, 
3.2) 
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Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  planning  process. 


V 

Output 

State 

References 

Action  items 
resulting  from 
reviews  with  senior 
management 

□  are  assigned.  (L2-26,  Vl,4) 

□  are  reviewed.  (L2-26,  Vl,4) 

□  are  tracked  to  closure.  (L2-26, 
VI.  4) 

Action  items 
resulting  from 
reviews  with  the 
project  manager 

□  are  assigned.  (L2-27,  V2,  6) 

□  are  reviewed.  (L2-27,  V2,  6) 

□  are  tracked  to  closure.  (L2-27, 
V2,6) 

Assumptions  made  in 
deriving  the  estimates 
for  the  software 
project’s  costs 

□  are  documented.  (L2-23,  A 10, 

4) 

□  are  reviewed.  (L2-23,  AlO,  4) 

□  are  agreed  to.  (L2-23,  AlO,  4) 

Assumptions  made  in 
deriving  the  estimates 
for  the  software 
project's  effort 

□  are  documented.  (L2-23,  AlO, 

4) 

□  are  reviewed.  (L2-23,  AIO,  4) 

□  are  agreed  to.  (L2-23,  AlO,  4) 

Assumptions  made  in 
deriving  the  (project’s 
software)  schedule 

are  documented,  (L2-24,  A 12,  5) 

Contingencies  for  the 
risks  (associated  with 
the  cost,  resource, 
schedule,  and 
technical  aspects  of 
the  project) 

are  identified.  (L2-24,  A13,  2) 

Critical  computer 
resources  for  the 
project 

are  identified.  (L2-23,  All,  1) 

Distributions  of  cost 
estimates  over  the 
software  life  cycle 

are  prepared.  (L2-23,  AlO,  3.3) 

Distributions  of 
effort  estimates  over 
the  software  life  cycle 

are  prepared.  (L2-23,  AiO,  3.3) 

Continued  on  next  page 
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SPP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  planning  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Distributions  of 
staffing  estimates 
over  the  software  life 
cycle 

are  prepared.  (L2-23,  A 10,  3.3) 

Estimates  for  the 
project's  critical 
computer  resources 

□  are  derived  according  to  a 
documented  procedure.  (L2-23, 
All) 

□  are  related  to  the  estimates  of: 
(L2-23,  All,  2) 

□  the  size  of  the  software  work 
products, 

□  the  operational  processing 
load,  and 

□  the  communications  traffic. 

□  are  documented.  (L2-23,  All, 

3) 

□  are  reviewed.  (L2-23,  A1 1,  3) 

□  are  agreed  to.  (L2-23,  A1 1,  3) 

Estimates  for  the  size 
of  the  software  work 
products  (or  changes 
to  the  size  of  software 
work  products) 

□  are  derived  according  to  a 
documented  procedure.  (L2-21, 
A9) 

□  are  made  for  alt  major  software 
work  products  and  activities. 
(L2-21,  A9,  1) 

□  are  documented.  (L2-21,  A9,  5) 

□  are  reviewed.  (L2-2 1 ,  A9,  5) 

□  are  agreed  to.  (L2-21,  A9,  5) 

Continued  on  next  page 
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SPP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  planning  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Estimates  for  the 
software  project's 
costs 

□  are  derived  according  to  a 
documented  procedure.  (L2-22, 
AlO) 

□  are  related  to  the  size  estimates  of 
the  software  work  products  (or 
the  size  of  the  changes).  (L2-22, 
AlO.  1) 

□  are  based  on  past  experience. 
(L2-22,  AlO.  3) 

Estimates  for  the 
software  project’s 
effort 

□  are  derived  according  to  a 
documented  procedure.  (L2-22, 
AlO) 

□  are  related  to  the  size  estimates  of 
the  software  work  products  (or 
the  size  of  the  changes).  (L2-22, 
AlO,  1) 

□  are  based  on  past  experience. 
^L2-22,  AlO,  3) 

Estimates  of  capacity 
requirements  for  (the 
project’s  software 
engineering)  facilities 
and  support  tools 

are  based  on  the  size  estimates  of  the 
software  work  products  and  other 
characteristics.  (L2-25,  A 14,  1) 

1 

Measurements  (to 
determine  the  status 
of  the  software 
planning  activities) 

are  made.  (L2-25,  Ml) 
are  used.  (L2-25,  Ml) 

Plans  for  involvement 
of  the  software 
engineering  group  in 
the  activities  of  other 
software-related 
groups  and  other 
engineering  groups 

are  negotiated  with  those  groups,  the 
support  efforts  are  budgeted,  and  the 
agreements  are  documented.  (L2- 
19,  A6.  3) 

Plans  for  software- 
related  groups  and 
other  engineering 
groups  involved  in 
the  activities  of  the 
software  engineering 
group 

are  negotiated  with  those  groups,  the 
support  efforts  are  budgeted,  and  the 
agreements  are  documented.  (L2- 
18,  A6.  2) 

1 

_ i 
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SPP  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  m  the  table  below 
to  exit  the  software  project  planning  process,  continued  from  the  previous  page. 


Output 

State 

References 

Plans  for  the 
project’s  software 
engineering  facilities 
and  support  tools 

□  are  prepared.  (L2-25,  A 14) 

□  are  reviewed  by  all  affected 
groups.  (L2-25,  A 14,  3) 

Project’s  software 
development  plan 

□  is  managed  and  controlled.  (L2- 
13,  C2,  6) 

□  is  developed  according  to  a 
documented  procedure.  (L2-18, 
A6) 

□  is  based  on  and  conforms  to: 
(L2-18,  A6,  1) 

□  the  customer’s  standards,  as 
appropriate; 

□  the  project’s  standards; 

□  the  approved  statement  of 
work;  and 

□  the  allocated  requirements. 

□  is  reviewed  by:  (L2-19,  A6,  4) 

□  the  project  manager, 

□  the  project  software 
manager, 

□  the  other  software  managers, 
and 

□  other  affected  groups. 

□  is  documented.  (L2-19,  A7) 

1 
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SPP  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  planning  process,  continued  from  the  previous  page. 


Output 

State 

References 

I 

Project's  software 
schedule 

□  is  derived  according  to  a 
documented  procedure.  (L2-23, 
A12) 

□  is  related  to;  (L2-24,  A12,  1) 

□  the  size  estimate  of  the 
software  work  products  (or 
the  size  of  changes),  and 

□  the  software  effort  and  costs. 

□  is  based  on  past  experience. 
(L2-24,  A 12,  2) 

□  Similar  projects  are  used 
when  possible. 

□  accommodates  the  imposed 
milestone  dates,  critical 
dependency  dates,  and  other 
constraints.  (L2-24,  A 12,  3) 

□  activities  are  of  appropriate 
duration  and  the  milestones  are 
of  appropriate  time  separation  to 
support  accuracy  in  progress 
measurement.  (L2-24,  A 12,  4) 

□  is  documented.  (L2-24,  A 12,  6) 

□  is  reviewed.  (L2-24,  A12,  6) 

□  is  agreed  to.  (L2-24,  A 12,  6) 

Results  (of  SQA 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  software  project 
planning) 

are  reported.  (L2-27,  V3) 

Size  estimating 
assumptions 

are  documented.  (L2-21,  A9,  4) 

Software  life  cycle 

□  is  identified  or  defined.  (L2-17, 
A5) 

□  has  predefined  stages  of 
manageable  size.  (L2-17,  A5) 

i 
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SPP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  planning  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Software  planning 
data 

□  are  recorded.  (L2-25,  A 15) 

□  Information  recorded 

includes  the  estimates  and  the 
associated  information 
needed  to  reconstruct  the 
estimates  and  as.sess  their 
reasonableness.  (L2-25, 

A15,  1) 

□  are  managed  and  controlled. 

(L2-25,  A15,  2) 

Software  project's 
commitments 

□  are  negotiated  between:  (L2-I2, 
C2,  2) 

□  the  project  manager, 

□  the  project  software 
manager,  and 

□  the  other  software 
managers. 

□  made  to  individuals  and  groups 
externa]  to  the  organization  are 
reviewed  with  senior 
management  according  to  a 
documented  procedure.  (L-17, 
A4) 

Software  risks 
associated  with  the 
cost,  resource, 
schedule,  and 
technical  aspects  of 
the  project 

□  are  identified.  (L2-24,  A 13) 

□  are  assessed.  (L2-24,  A13) 

□  are  documented.  (L2-24,  A13'' 

□  are  analyzed.  (L2-24,  A13,  >) 

□  are  prioritized  based  on  their 
potential  impact  to  the  project. 
(L2-24,  A 13,  1) 

Software  work 
products 

are  decomposed  to  the  granularity 
needed  to  meet  the  estimating 
objective.s.  (L2-21,A9,  2) 
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SPP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  planning  process,  continued  from  the  previous  page. 


T 

Output 

State 

References 

Software  work 
products  that  are 
needed  to  establish 
and  maintain  control 
of  the  software 
project 

are  identified.  (L2-20,  A8) 

Sources  for 
productivity  data  tha. 
are  used  to  esimate 
the  software  pro/  ct's 
effort  and  costs 

are  documented.  (L2-22,  A 10,  2) 

Rationale  for 
productivity  data  that 
are  .jo^d  to  estir  late 
the  software  pro 
.  Toit  and  costs 

•  "  documented.  (L2-22,  A 10,  2) 

.attlng  estimates 

are  based  on  past  experierce.  (L2- 
22,  AlO,  3^ 

Summary  rep'.n 
fnm  each  mer' 

.1  senior 
management 

□  is  prepared.  (L2-26,  Vl,5) 

■ '  distributed  to  the  affected 
,;roups  and  individuals.  (L2-26, 
VI.  5) 

Summary  report 
from  each  meetmg 
with  the  project 
manager 

Cj  is  prepared.  (L2-27,  V2,  7) 

□  is  distributed  to  the  affected 
groups  and  individuals.  (L2-27, 
V2,  7^ 

Time  phasing  of 
activities 

is  derived.  (L2-22,  AlO,  3.2) 
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SPP  Process  -  Exit  Criteria,  continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  project  planning  process. 


Condition 

References 

The  system  requirements  allocated  to  software  are  used  as 
the  basis  for  planning  the  software  project.  (L2-12,  C2,  1) 

Involvement  of  other  engineering  groups  in  the  software 
activities  is  negotiated  with  these  groups  and  is  documented. 
(L2-13.  C2.  3) 

Affected  groups  review  the  project’s;  (L2-13,  C2,  4) 

□  software  size  estimates, 

□  effort  and  cost  estimates, 

□  schedules,  and 

□  other  commitments. 

Senior  management  reviews  all  software  project 
commitments  made  to  individuals  and  groups  external  to 
the  organization.  (L2-13,  C2,  5) 

The  software  engineering  group  participates  on  the  project 
proposal  team.  (L2-16,  Al) 

The  software  engineering  group  reviews  the  project’s 
proposed  commitments.  (L2-17,  Al,  2) 

The  software  engineering  group  participates  with  other 
affected  groups  in  the  overall  project  planning  throughout 
the  project’s  life.  (L2-17,  A3) 

The  software  engineering  group  reviews  the  project-level 
plans.  (L2-17,  A3,  1) 

Productivity  data  (historical  and/or  current)  are  used  for  the 
estimates  when  available.  (L2-22,  A 10,  2) 

Responsibilities  are  assigned  and  commitments  are 
negotiated  to  procure  or  develop  the  project's  facilities  and 
tools.  (L2-25,  A14,  2) 

The  activities  for  software  project  planning  are  reviewed  with 
senior  management  on  a  periodic  basis.  (L2-26,  VI) 

The  activities  for  software  project  planning  are  reviewed  with 
the  project  manager  on  both  a  periodic  and  event-driven 
basis.  (L2-26,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  project 
planning,  and  reports  the  results.  (L2-27,  V3) 
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SPP  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  project 
planning  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

Affected  groups  review  the  software 
project’s:  (L2-13,  C2,  4) 

□  software  size  estimates, 

□  effort  and  cost  estimates, 

□  schedules,  and 

□  other  commitments. 

Affected 

groups 

Senior  management  reviews  all  software 
project  commitments  made  to  individuals 
and  groups  external  to  the  organization. 
(L2-13,  C2,  5) 

Senior 

management 

The  statement  of  work  is  reviewed  by: 
(L2-15,  Abl,  2) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

Project 

manager 

Project 

software 

manager 

Software 

managers 

Affected 

groups 

The  software  engineering  group  reviews 
the  project's  proposed  commitments.  (L2- 
17,  Al,  2) 

Softw.'Te 

engineering 

group 

The  software  engineering  group  reviews 
the  project-level  plans.  (L2-17,  A3,  1) 

Software 

engineering 

group 

Software  project  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management.  (L2'17,  A4) 

Senior 

management 

The  software  development  plan  is  reviewed 
by:  (L2-19,  A6,  4) 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

Project 

manager 

Project 

software 

manager 

Software 

managers 

Affected 

groups 
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SPP  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  project 
planning  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

Size  estimates  are  documented,  reviewed, 
and  agreed  to.  (L2-21,  A9,  5) 

Not  specified  in 
the  CMM 

Estimates  and  the  assumptions  made  in 
deriving  the  estimates  are  documented, 
reviewed,  and  agreed  to.  (L2-23,  A 10,  4) 

Not  specified  in 
the  CMM 

Estimates  of  the  critical  computer  resources 
are  documented,  reviewed,  and  agreed  to. 
(L2-23,  All,  3) 

Not  specified  in 
the  CMM 

The  software  schedule  is  documented, 
reviewed,  and  agreed  to.  (L2-24,  A 12,  6) 

Not  specified  in 
the  CMM 

The  plans  for  the  project’s  software 
engineering  facilitie.s  and  support  tools  are 
reviewed  by  all  affected  groups.  (L2-25, 
A14,  3) 

Affected 

groups 

The  activities  for  software  project  planning 

are  reviewed  with  senior  management  on  a 

periodic  basis.  (L2-26,  VI) 

□  The  technical,  cost,  staffing,  and 
schedule  performance  is  reviewed. 

□  Conflicts  and  issues  not  resolvable  at 
lower  levels  are  addressed. 

□  Software  project  risks  are  addressed. 

□  Action  items  are  assigned,  reviewed, 
and  tracked  to  closure. 

□  A  summary  report  from  each  meeting 
is  prepared  and  distributed  to  the 
affected  groups  and  individuals. 

Senior 

management 

Affected 
groups  and 
individuals 
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SPP  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  project 
planning  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

The  activities  for  software  project  planning 

are  reviewed  with  the  project  manager  on 

both  a  periodic  and  event-driven  basis. 

(L2-26,  V2) 

□  Affected  groups  are  represented. 

□  Status  and  current  results  of  the 
software  project  planning  activities  are 
reviewed  against  the  software  project's 
statement  of  work  and  allocated 
requirements. 

□  Deperr- ‘-etv  .'t  groups  are 
addr  u. 

□  C'  -  r  iO  issues  not  resolvable  at 
low  ,'vels  are  addressed. 

□  Softwaie  project  risks  are  reviewed. 

□  Action  items  are  assigned,  reviewed, 
and  tracked  to  closure. 

□  A  summary  report  from  each  meeting 
is  prepared  and  distributed  to  the 
affected  groups  and  individuals. 

Project 

manager 

Affected 

groups 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  project  planning  and 
reports  the  results.  {L2-27,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify; 

□  The  activities  for  software  estimating 
and  planning. 

□  The  activities  for  reviewing  and  making 
project  commitments. 

□  The  activities  for  preparing  the 
software  development  plan. 

□  The  standards  used  for  preparing  the 
software  development  plan. 

□  The  content  of  the  software 
development  plan. 

SQA  group 
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SPP  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  managed  and 
controlled  during  the  software  project  planning  process. 


V 

Work  Products  Managed  and  Controlled 

References 

Project’s  software  development  plan.  (L2-I3,  C2,  6) 

Statement  of  work.  (L2-15,  Abl,  3) 

i 

Software  planning  data.  (L2-25,  A 15,  2) 
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SPP  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software  project 
planning  process. 


V 

Measurements 

References 

Software  planning  data.  (L2-25,  A 15) 

□  Information  recorded  includes  the  estimates  and  the 
associated  information  needed  to  reconstruct  the 
estimates  and  assess  their  reasonableness.  (L2-25,  A15, 

1) 

Measurements  are  made  and  used  to  determine  the  status  of 

the  software  planning  activities.  (L2-25,  Ml) 

Examples  of  measurements  include: 

□  Completions  of  milestones  for  the  software  project 
planning  activities  compared  to  the  plan. 

□  Work  completed,  effort  expended,  and  funds  expended 
in  the  software  project  planning  activities  compared  to 
the  plan. 
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SPP  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  software  project  planning  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


V 

Documented  procedures 

References 

Software  project  commitments  made  to  individuals  and 
groups  externa!  to  the  organization  are  reviewed  with 
senior  management  according  to  a  documented  procedure. 
(L2-17,  A4) 

The  project’s  software  development  plan  is  developed 
according  to  a  documented  procedure.  (L2-I8,  A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Estimates  for  the  size  of  the  software  work  products  (or 
changes  to  the  size  of  software  work  products)  are  derived 
according  to  a  documented  procedure.  (L2-21,  A9) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Estimates  for  the  software  project’s  effort  and  costs  are 
derived  according  to  a  documented  procedure.  (L2-22, 

AlO) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Estimates  for  the  project’s  critical  computer  resources  are 
derive  J  according  to  a  documented  procedure.  (L2-23, 

All) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  project’s  software  schedule  is  derived  according  to  a 
documented  procedure.  (L2-23,  A 12) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 
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SPP  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  project  planning 
process. 


Training 

References 

The  software  managers,  software  engineers,  and  other 
individuals  involved  in  the  software  project  planning  are 
trained  in  the  software  estimating  and  planning  procedures 
applicable  to  their  areas  of  responsibility.  (L2-16,  Ab4) 
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SPP  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  software  project  planning 
process. 


Tools 

References 

Tools  to  support  software  project  planning  activities.  (L2- 
16,  Ab3,  2) 

Examples  of  support  tools  include: 

□  spreadsheet  programs, 

□  estimating  models,  and 

□  project  planning  and  scheduling  programs. 
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Software  Project  Tracking  and  Oversight  (SPTO)  Process 
SPTO  Process  -  Overview 


SPTO  process 
purpose 


SPTO  process 
description 


The  purpose  of  Software  Project  Tracking  and  Oversight  is  to  provide  adequate 
visibility  into  actual  progress  so  that  management  can  take  effective  actions  when 
the  software  project's  performance  deviates  significantly  from  the  software  plans. 
(L2-29) 


Software  Project  Tracking  and  Oversight  involves  tracking  and  reviewing  the 
software  accomplishments  and  results  against  documented  estimates,  commitments, 
and  plans,  and  adjusting  these  plans  based  on  the  actual  accomplishments  and 
results. 

A  documented  plan  for  the  software  project  (i.e.,  the  software  development  plan,  as 
described  in  the  Software  Project  Planning  key  process  area)  is  used  as  the  basis  for 
tracking  the  software  activities,  communicating  status,  and  revising  plans.  Software 
activities  are  monitored  by  the  management.  Progress  is  primarily  determined  by 
comparing  the  actual  software  size,  effort,  cost,  and  schedule  to  the  plan  when 
selected  software  work  products  are  completed  and  at  selected  milestones.  When  it 
is  determined  that  the  software  project's  plans  are  not  being  met,  corrective  actions 
are  taken.  These  actions  may  include  revising  the  software  development  plan  to 
reflect  the  actual  accomplishments  and  replanning  the  remaining  work  or  taking 
actions  to  improve  the  performance.  (L2-29) 


Continued  on  next  page 
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SPTO  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L2-Process-61 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L2-Process-68 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L2-Process-70 

Activities 

Description  of  the  activities  of  the 
process. 

L2-Process-71 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L2-Process-75 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L2-Process-79 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L2-Pfocess-88 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L2-Process*92 

Measurements 

Description  of  process  measurements. 

L2-Process-93 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L2-Process-94 

Training 

List  of  training. 

L2-Process-95 

Tools 

List  of  tools. 

L2-Process-96 

L2-Process-60 
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SPTO  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  tracking  and  oversight  process. 


Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

□  Changes  to  the  software  commitments 
are  made  with  the  involvement  and 
agreement  of  the  affected  groups.  (L2- 
30,  C2. 4) 

□  Changes  in  size  estimates  of  the 
software  work  products  that  affect 
software  commitments  are  negotiated 
with  the  affected  groups  and  are 
documented.  (L2-36,  A5,  5) 

□  Changes  in  staffing  and  other  software 
costs  that  affect  software  commitments 
are  negotiated  with  the  affected  groups 
and  are  documented.  (L2-36,  A6,  4) 

□  Changes  in  estimates  of  critical 
computer  resources  that  affect  software 
commitments  are  negotiated  with  the 
affected  groups  and  are  documented. 
(L2-37,  A7,  2) 

□  Software  schedule  revisions  that  affect 
software  commitments  are  negotiated 
with  the  affected  groups  and  are 
documented.  (L2-37,  A8,  3) 

□  Formal  reviews  to  address  the 
accomplishments  and  results  of  the 
software  project  are  conducted  at 
selected  project  milestones  according  to 
a  documented  procedure.  (L2-39, 

A13) 

These  reviews: 

□  Are  conducted  with  the  customer, 
end  user,  and  affected  groups 
within  the  organization,  as 
appropriate,  (.l.2-39,  A 13,  2) 

□  A  summary  status  report  from  each 
review  (meeting)  with  senior 
management  is  prepared  and 
distrib^uted  to  t'.ie  affected  groups.  (L2- 
40,  VI,  5) 

! 

Role  continues  on  the  next  page 


Com  mcd  on  next  page 
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SPTO  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  tracking  and  oversight  process,  continued  from  the  previous  page. 


rr 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups, 

continued 

□  The  activities  for  software  project 
tracking  and  oversight  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
41.  V2) 

□  Affected  groups  are  represented. 
(L2-41.  V2,  1) 

□  A  summary  status  report  from  each 
(review  meeting)  with  the  project 
manager  is  prepared  and 
distributed  to  the  affected  groups. 
(L2-41,  V2,  8) 

Customer 

□  Formal  reviews  to  address  the 
accomplishments  and  results  of  the 
software  project  are  conducted  at 
selected  project  milestones  according  to 
a  documented  procedure.  (L2-39, 

A13) 

These  reviews: 

□  Are  conducted  with  the  customer, 
end  user,  and  affected  groups 
within  the  organization,  as 
appropriate.  (L2-39,  A 13,  2) 

i 

{ _ 

End  user 

□  Formal  reviews  to  address  the 
accomplishments  and  results  of  the 
software  project  are  conducted  at 
selected  project  milestones  according  to 
a  documented  procedure.  (L2-39, 

A13) 

These  reviews: 

□  Are  conducted  with  the  customer, 
end  user,  and  affected  groups 
within  the  organization,  as 
appropriate.  (L2-39,  A13,  2) 

Continuzd  on  next  page 
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SPTO  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  tracking  and  oversight  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

First-line 

software 

managers 

□  First-line  software  managers  receive 
orientation  in  the  technical  aspects  of 
the  software  project.  (L2-32,  Ab5) 

□  Members  of  the  software  engineering 
group  report  their  technical  status  to 
their  first-line  manager  on  a  regular 
basis.  (L2-37,  A9,  1 ) 

□  The  software  engineering  group 
conducts  periodic  internal  reviews  to 
track  technical  progress,  plans, 
performance,  and  issues  against  the 
software  development  plan.  (L2-38, 
A12) 

These  reviews  are  conducted  between: 

□  The  first-line  software  managers 
and  their  software  task  leaders. 

□  The  project  software  manager,  first- 
line  software  managers,  and  other 
software  managers,  as  appropriate. 

Individuals 
and  groups 
external  to  the 
organization 

□  Senior  management  reviews  all 
commitment  changes  and  new  software 
project  commitments  made  to 
individuals  and  groups  external  to  the 
organization.  (L2-31,C2,  5) 

□  Software  project  commitments  and 
changes  to  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management  according  to  a 
documented  procedure.  (L2-35,  A3) 

Continued  on  next  page 
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SPTO  PrOC6SS  -  RolOS,  continued 


Roles,  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

continued  software  project  tracking  and  oversight  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Project 

manager 

□  The  project  manager  is  kept  informed 
of  the  software  project's  status  and 
issues.  (L2-30,  C2,  2) 

□  High-risk  areas  associated  with  cost, 
resource,  schedule,  and  technical 
aspects  of  the  project  are  reviewed  with 
the  project  manager  on  a  regular  basis. 
(L2-38,  AlO,  2) 

□  The  activities  for  software  project 
tracking  and  oversight  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
41,  V2) 

Project 

software 

manager 

□  A  project  software  manager  is 
designated  to  be  responsible  for  the 
project’s  software  activities  and  results. 
(L2-30,  Cl) 

□  The  project  software  manager 
explicitly  assigns  responsibility  for 
software  work  products  and  activities. 
(L2-31,  Ab2) 

□  The  software  engineering  group 
conducts  periodic  internal  reviews  to 
track  technical  progress,  plans, 
performance,  and  issues  against  the 
software  development  plan.  (L2-38, 
A12) 

These  reviews  are  conducted  between: 

□  The  first-line  software  managers 
and  their  software  task  leaders. 

□  The  project  software  manager, 
first-line  software  managers,  and 
other  software  managers,  as 
appropriate. 

Continued  on  next  page 
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SPTO  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  tracking  and  oversight  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Senior 

management 

□  Senior  management  reviews  all 
commitment  changes  and  new  software 
project  commitments  made  to 
individuals  and  groups  external  to  the 
organization.  (L2-31,  C2,  5) 

□  Software  project  commitments  and 
changes  to  commitments  made  to 
individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior 
management  according  to  a 
documented  procedure.  (L2-35,  A3) 

□  The  activities  for  software  project 
tracking  and  oversight  are  reviewed 
with  senior  management  on  a  periodic 
basis.  (L2-40,  VI) 

Software 

engineering 

group 

□  Approved  changes  to  commitments  that 
affect  the  software  project  are 
communicated  to  the  members  of  the 
software  engineering  group  and  other 
software-related  groups.  (L2-35,  A4) 

□  Members  of  the  software  engineering 
group  report  their  technical  status  to 
their  first-line  manager  on  a  regular 
basis.  (L2-37,  A9,  1) 

□  The  software  engineering  group 
conducts  periodic  internal  reviews  to 
track  technical  pi  ogress,  plans, 
performance,  and  issues  against  the 
software  development  plan.  (L2-38, 
A12) 

Continued  on  next  page 
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SPTO  Process  -  Roles,  Continued 


Roles,  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

continued  software  project  tracking  and  oversight  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software 

manager 

□  The  software  managers  and  the 
software  task  leaders  are  assigned 
specific  re.sponsibilities  for  tracking  the 
software  project.  (L2-32,  Ab3,  1) 

□  The  software  managers  are  trained  in 
managing  the  technical  and  personnel 
aspects  of  the  software  project.  (L2-32, 
Ab4) 

□  The  software  engineering  group 
conducts  periodic  internal  reviews  to 
track  technical  progress,  plans, 
performance,  and  issues  against  the 
software  development  plan.  (L2-38, 
A12) 

These  reviews  are  conducted  between; 

□  The  first-line  software  managers 
and  their  software  task  leaders. 

□  The  project  software  manager,  first- 
line  software  managers,  and  other 
software  managers,  as  appropriate. 

□  Formal  review  to  address  the 
accomplishments  and  results  of  the 
software  project  are  conducted  at 
selected  project  milestones  according  to 
a  documented  procedure.  (L2-39, 

A13) 

These  reviews: 

□  Use  materials  that  are  reviewed  and 
approved  by  the  responsible 
software  managers.  (L2-39,  A13, 
3) 

Continued  on  next  page 
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SPTO  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  project  tracking  and  oversight  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software- 
related  groups 

Approved  changes  to  commitments  that 
affect  the  software  project  are 
communicated  to  the  members  of  the 
software  engineering  group  and  other 
software-related  group.s.  (L2-35,  A4) 

SQA  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  project  tracking  and 
oversight  and  reports  the  results.  (L2-41, 
V3) 

Software  task 
leaders 

□  The  software  managers  and  the 
software  task  leaders  are  assigned 
specific  responsibilities  for  tracking  the 
software  project.  (L2-32,  Ab3,  1) 

□  The  softwaie  engineering  group 
conducts  periodic  internal  reviews  to 
track  technical  progress,  plans, 
performance,  and  issues  against  the 
software  development  plan.  (L2-38, 
A12) 

These  reviews  are  conducted  between: 

□  The  first-line  software  managers 
and  their  software  task  leaders. 

□  The  project  software  manager,  first- 
line  software  managers,  and  other 
software  managers,  as  appropriate. 
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Input-based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  software  project  tracking  and  oversight  process. 


T 

Input 

State 

References 

Software 

development  plan 
(for  the  software 
project) 

□  is  documented.  (L2-31,  Abl) 

□  is  approved.  (L2-31,  Abl) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  project  tracking  and  oversight  process. 


V 

Condition 

References 

A  project  software  manager  is  designated  to  be  responsible 
for  the  project's  software  activities  and  results.  (L2-30,  Cl) 

The  project  follows  a  written  organizational  policy  for 
managing  the  software  project.  (L2-30,  C2) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  SPTO  policy.] 

A  software  development  plan  for  the  software  project  is 
documented  and  approved.  (L2-31,  Abl) 

The  project  software  manager  explicitly  assigns 
responsibility  for  software  work  products  and  activities. 
(L2-31,  Ab2) 

The  assigned  responsibilities  cover: 

□  The  software  work  products  to  be  developed  or  services 
to  be  provided. 

□  The  effort  and  cost  for  these  software  activities. 

□  The  schedule  for  these  software  activities. 

□  The  budget  for  these  software  activities. 

Adequate  resources  and  funding  are  provided  for  tracking 
the  software  project.  (L2-32,  Ab3) 

The  software  managers  and  the  software  task  leaders  are 
assigned  specific  responsibilities  for  tracking  the  software 
project.  (L2-32,  AbX  1) 

Tools  to  support  software  tracking  are  made  available.  (L2- 
32,  Ab3,  2) 

'  mu  nied  on  next  page 
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General  entry 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  project  tracking  and  oversight  process,  continued 
from  the  previous  page. 


V 

Condition 

References 

The  software  managers  are  trained  in  managing  the 
technical  and  personnel  aspects  of  the  software  project.  (L2- 
32,  Ab4) 

First'line  software  managers  receive  orientation  in  the 
technical  aspects  of  the  software  project.  (L2-32,  Ab5) 
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Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  project  tracking  and 
oversight  process. 


V 

Input 

Org.  Input 

References 

Changes  to  commitments.  (L2-34,  A2,  2) 

Changes  to  the  software  development  plan. 
(L2-34,  A2,  1) 

New  software  project  commitments.  (L2- 
34,  A2,  2) 

Refinements  to  the  software  development 
plan.  (L2-34,  A2,  1) 

Software  commitments.  (L2-36,  A5,  5) 

Software  development  plan.  (L2-30,  Cl) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  a  software 
development  plan.] 

Software  planning  data.  (L2-38,  All,  3) 
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Activities 


The  table  below  lists  the  recommended  activities  for  the  software  project  tracking 
and  oversight  process. 


< 

Activities 

References 

A  documented  software  development  plan  is  used  for 
tracking  the  software  activities  and  communicating  status. 
(L2-33,  Al) 

□  This  software  development  plan  is  updated  as  the  work 
progresses  to  reflect  accomplishments,  particularly  when 
milestones  are  completed.  (L2-33,  Al,  1) 

The  project's  software  development  plan  is  revised  according 
to  a  documented  procedure.  (L2-33,  A2) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Software  project  commitments  and  changes  to  commitments 
made  to  individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior  management 
according  to  a  documented  procedure.  (L2-35,  A3) 

Approved  changes  to  commitments  that  affect  the  software 
project  are  communicated  to  the  members  of  the  software 
engineering  group  and  other  software>reIated  groups. 
(L2-35,  A4) 

The  size  of  the  software  work  products  (or  size  of  the 

changes  to  the  software  work  products)  are  tracked,  and 

corrective  actions  are  taken  as  necessary.  (L2-35,  A5) 

□  Sizes  for  all  major  software  work  products  (or  the  size  of 
the  changes)  are  tracked. 

□  Actual  size  of  code  (generated,  fully  tested,  and 
delivered)  is  compared  to  the  estimates  documented  in 
the  software  development  plan. 

□  Actual  units  of  delivered  documentation  are  compared 
to  the  estimates  documented  in  the  software  development 
plan. 

□  Overall  projected  size  of  the  software  work  products 
(estimates  combined  with  actuals)  is  refined,  monitored, 
and  adjusted  on  a  regular  basis. 

□  Changes  in  size  estimates  of  the  software  work  products 
that  affect  software  commitments  are  negotiated  with  the 
affected  groups  and  are  documented. 

Com  nued  on  next  page 
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SPTO  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  project  tracking 
and  oversight  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  project's  software  effort  and  costs  are  tracked,  and 

corrective  actions  are  taken  as  necessary.  (L2-36,  A6) 

□  Actual  expenditures  of  effort  and  costs  over  time  and 
against  work  completed  are  compared  to  the  estimates 
documented  in  the  software  development  plan  to 
identify  potential  overruns  and  underruns. 

□  Software  costs  are  tracked  and  compared  to  the  estimates 
documented  in  the  software  development  plan. 

□  Effort  and  staffing  are  compared  to  the  estimates 
documented  in  the  software  development  plan. 

□  Changes  in  staffing  and  other  software  costs  that  affect 
software  commitments  are  negotiated  with  the  affected 
groups  and  are  documented. 

The  project's  critical  computer  resources  are  tracked,  and 
corrective  actions  are  taken  as  necessary.  (L2-36,  A7) 

□  The  actual  and  projected  use  of  the  project's  critical 
computer  resources  are  tracked  and  compared  to  the 
estimates  for  each  major  software  component  as 
documented  in  the  software  development  plan. 

□  Changes  in  estimates  of  critical  computer  resources  that 
affect  software  commitments  are  negotiated  with  the 
affected  groups  and  are  documented. 

The  project's  software  schedule  is  tracked,  and  corrective 

actions  are  taken  as  necessary.  (L  2-37,  A8) 

□  Actual  completion  of  software  activities,  milestones,  and 
other  commitments  is  compared  against  the  software 
development  plan. 

□  Effects  of  late  and  early  completion  of  software 
activities,  milestones,  and  other  commitments  are 
evaluated  for  impacts  on  future  activities  and  milestones. 

□  Software  schedule  revisions  that  affect  software 
commitments  are  negotiated  with  the  affected  groups 
and  are  documented. 

Continued  on  next  page 
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SPTO  Process  -  Activities.  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  project  tracking 
and  oversight  process,  continued  from  the  previous  page. 


Activities 

References 

Software  engineering  technical  activities  are  tracked,  and 

corrective  actions  are  taken  as  necessary.  (L2-37,  A9) 

□  Members  of  the  software  engineering  group  report  their 
technical  status  to  their  first-line  manager  on  a  regular 
basis. 

n  Software  release  contents  for  successive  builds  are 
compared  to  the  plans  documented  in  the  software 
development  plan. 

□  Problems  identified  in  any  of  the  software  work  products 
are  reported  and  documented. 

□  Problem  reports  are  tracked  to  closure. 

The  software  risks  associated  with  cost,  resource,  schedule, 
and  technical  aspects  of  the  project  are  tracked.  (L2-37, 

AlO) 

□  The  priorities  of  the  risks  and  the  contingencies  for  the 
risks* are  adjusted  as  additional  information  becomes 
available. 

□  High-risk  areas  are  reviewed  with  the  project  manager 
on  a  regular  basis. 

Actual  measurement  data  and  replanning  data  for  the 

software  project  are  recorded,  (L2-38,  All) 

□  Information  recorded  includes  the  estimates  and 
associated  information  needed  to  reconstruct  the 
estimates  and  verify  their  reasonableness. 

□  The  software  replanning  data  are  managed  and 
controlled. 

□  The  software  planning  data,  replanning  data,  and  the 
actual  measurement  data  are  archived  for  u.«e  by 
ongoing  and  future  projects. 

The  software  engineering  group  conducts  periodic  internal 
reviews  to  track  technical  progress,  plans,  performance,  and 
issues  against  the  software  development  plan.  (L2-38,  A 12) 

[Refer  to  SPTO  Process  Reviews  and  Audits  for  additional 
information.] 

Continued  on  next  page 
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SPTO  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  project  tracking 
and  oversight  process,  continued  from  the  previous  page. 


Activities 

References 

Formal  reviews  to  address  the  accomplishments  and  results 
of  the  software  project  are  conducted  at  selected  project 
milestones  according  to  a  documented  procedure.  (L2-39, 
A13) 

[Refer  to  SPTO  Process  Reviews  and  Audits  for  additional 
information.] 

Measurements  are  made  and  used  to  determine  the  status  of 
the  software  tracking  and  oversight  activities.  (L2-39,  Ml) 

The  activities  for  software  project  tracking  and  oversight  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L2- 
40.  VI) 

[Refer  to  SPTO  Process  Reviews  and  Audits  for  additional 
information.] 

The  activities  for  software  project  tracking  and  oversight  are 
reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-41,  V2) 

[Refer  to  SPTO  Process  Reviews  and  Audits  for  additional 
information.] 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  project  tracking 
and  oversight  and  reports  the  results.  (L2-4],  V3) 

[Refer  to  SPTO  Process  Reviews  and  Audits  for  additional 
information.] 
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SPTO  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  project 
tracking  and  oversight  process. 


11 

Output 

Org.  Output 

References 

Action  items  (from  reviews  with  senior 
management).  (L2-40,  V1.4) 

Action  items  (from  reviews  with  the  project 
manager).  (L2-41,V2,  7) 

Actual  completion  of  milestones.  (L2-37, 
A8,  1) 

Actual  completion  of  other  (software) 
commitments.  (L2-37,  A8,  1) 

Actual  completion  of  software  activities. 
(L2-37,  A8,  1) 

Actual  expenditures  of  costs  over  time  and 
against  work  completed.  (L2-36,  A6,  1) 

Actual  expenditures  of  effort  over  time  and 
against  work  completed.  (L2-36,  A6,  1) 

Actual  measurement  data  for  the  software 
project.  (L2-38,  All) 

Actual  replanning  data  for  the  software 
project.  (L2-38,  All) 

Actual  size  of  code  (generated,  fully  tested, 
and  delivered).  (L2-35,  A5,  2) 

Actual  units  of  delivered  documentation. 
(L2-35,  A5,  3) 

Actual  use  of  the  project’s  critical  computer 
resources.  (L2-36,  A7,  1) 

Approved  changes  to  commitments  that 
affect  the  software  project.  (L2-35,  A4) 

1 

Changes  in  estimates  of  critical  computer 
resources  that  affect  software 
commitments.  (L2-37,  A7,  2) 

Changes  in  size  estimates  of  the  software 
work  products  that  affect  software 
commitments.  (L2-36,  A5,  5) 

Changes  in  staffing  and  other  software 
costs  that  affect  software  commitments. 
(L2-36,  A6.  4) 

! _ 

Changes  to  commitments  made  to 

individuals  and  groups  external  to  the 
organization.  (L2-36.  A3) 

! 

j 

i 

1 

1 

Continued  on  next  page 
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SPTO  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  project 
tracking  and  oversight  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Changes  to  the  software  commitments. 
(L2-31,  C2,  5) 

Conflicts  and  issues  (not  resolvable  at  lower 
levels).  (L2-40,  V1.2) 

Contingencies  for  the  (software)  risks. 
(L2-38,  AlO,  1) 

Corrective  actions  (taken  when  the  software 
plan  is  not  being  achieved).  (L2-30,  C2,  3) 

Current  estimates  and  actual  use  of  critical 
computer  resources.  (L2-41,  V2,  3) 

Effects  of  late  and  early  completion  of 
software  activities,  milestones,  and  other 
commitments.  (L2-37,  A8,  2) 

Effort  and  staffing.  (L2-36,  A6,  3) 

High-risk  areas.  (L2-38,  AlO,  2) 

Measurements  (to  determine  the  status  of 
the  software  tracking  and  oversight 
activities).  (L2-39,  Ml) 

New  software  project  commitments  made 
to  individuals  and  groups  external  to  the 
organization.  (L2-31,  C2.  5) 

Overall  projected  size  of  the  software  work 
products  (estimates  combined  with  actuals). 
(L2-35,  A5,  4) 

Performance  (cost).  (L2-40,  VI,  1) 

Performance  (schedule).  (L2-40,  VI,  1) 

Performance  (staffing).  (L2-40,  VI,  1) 

Performance  (technical).  (L2-40,  VI,  1) 

Priorities  of  the  (software)  risks.  (L2-38, 
AlO,  1) 

Problem  reports.  (L2-37,  A9,  4) 

Problems  identified  in  any  of  the  software 
work  products.  (L2-37.  A9,  3) 

Projected  use  of  the  project's  critical 
computer  resources.  (L2-36,  A7,  1 ) 

Project's  critical  computer  resources.  (L2- 
36,  A7) 

Continued  on  next  page 
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SPTO  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  project 
tracking  ar.d  oversight  process,  continued  from  the  previous  page. 


v" 

Output 

Org.  Output 

References 

Project's  software  costs.  (L2-36,  A6) 

Project’s  software  effort  (L2-36,  A6) 

Project’s  software  schedule.  (L2-37,  A8) 

Results  of  SQA  group  reviews  and/or 
audits  of  the  activities  and  work  products 
for  software  project  tracking  and  oversight. 
(L2-41,  V3) 

Size  of  the  changes  to  the  software  work 
products.  (L2-35,  A5) 

Size  of  the  software  work  products.  (L2' 

35,  A5) 

Sizes  for  all  major  software  work  products. 
(L2-35,  A5,  I) 

Sizes  of  the  changes  to  all  major  software 
work  products.  (L2-35,  A5,  1 ) 

Software  costs.  (L2-36,  A6,  2) 

Software  development  plan.  (L2-33,  A2) 

Software  planning  data.  (L2-38,  All,  3) 

Software  project  commitments  made  to 
individuals  and  groups  external  to  the 
organization.  (L2-35,  A3) 

Software  project  risks.  L2-40,  VI,  3) 

Software  project’s  status  and  issues.  (L2- 
30,  C2,  2) 

Software  release  contents  for  successive 
builds.  (L2-37,  A9,  2) 

Software  risks  associated  with  cost  aspects 
of  the  project.  (L2-37,  A 10) 

Software  risks  associated  with  resource 
aspects  of  the  project.  (L2-37,  A 10) 

Software  risks  associated  with  schedule 
aspects  of  the  project.  (L2-37,  A 10) 

Software  risks  associated  with  technical 
aspects  of  the  project.  (L2-37,  A 10) 

» 
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SPTO  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  project 
tracking  and  oversight  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Software  schedule  revisions  that  affect 
software  commitments.  (L2-37.  A8,  3) 

Status  of  software  activities.  (L2-33,  Al) 

Summary  report  from  each  review  of 
activities  for  software  project  tracking  and 
oversight  with  the  project  manager.  (L2- 
41,  V2,  8) 

Summary  status  report  from  each  periodic 
review  of  activities  for  software  project 
tracking  and  oversight  with  senior 
management.  (L2-40,  Vl,5) 
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SPTO  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process. 


Output 

State 

References 

Action  items  (from 
reviews  with  senior 
management) 

□  are  assigned.  (L2-40,  Vl,4) 

□  are  reviewed.  (L2-40,  Vl,4) 

□  are  tracked  to  closure.  (L2-40, 

VI.  4) 

Action  items  (from 
reviews  with  the 
project  manager) 

□  are  assigned.  (L2-41,  VI,  1) 

□  are  reviewed.  (L2-41,V2,  7) 

□  are  tracked  to  closure.  (L2-41, 
VI,  7) 

Actual  completion  of 
milestones 

is  compared  against  the  software 
development  plan.  (L2-37,  A8,  1) 

Actual  completion  of 
other  (software) 
commitments 

is  compared  against  the  software 
development  plan.  (L2-37,  A8,  1) 

Actual  completion  of 
software  activities 

is  compared  against  the  software 
development  plan.  (L2-37,  A8,  1) 

Actual  expenditures 
of  costs  over  time 
and  against  work 
completed 

are  compared  to  the  estimates 
documented  in  the  software 
development  plan  to  identify 
potential  overruns  and  underruns. 
(L2-36,  A6,  1) 

Actual  expenditures 
of  effort  over  time 
and  against  work 
completed 

are  compared  to  the  estimates 
documented  in  the  software 
development  plan  to  identify 
potential  overruns  and  underruns. 
(L2-36,  A6,  1) 

Actual  measurement 
data  for  the  software 
project 

□  are  recorded.  (L2-38,  All) 

□  include  in  the  information 
recorded  the  estimates  and 
associated  information  needed  to 
reconstruct  the  estimates  and 
verify  their  reasonableness.  (L2- 
38,  All,  1) 

□  are  archived  for  use  by  ongoing 
and  future  projects.  (L2-38, 

All,  3) 
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SPTO  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 
previous  page. 


Output 

State 

References 

Actual  replanning 
data  for  the  software 
project 

□  are  recorded.  (L2-38,  All) 

□  include  in  the  information 
recorded  the  estimates  and 
associated  information  needed  to 
reconstruct  the  estimates  and 
verify  their  reasonableness.  (L2- 
38,  All.  1) 

□  are  managed  and  controlled. 
(L2-38,  All,  2) 

□  are  archived  for  use  by  ongoing 
and  future  projects.  (L2-38, 

All,  3) 

Actual  size  of  code 
(generated,  fully 
tested,  and  delivered) 

is  compared  to  the  estimates 
documented  in  the  software 
development  plan.  (L2-35,  A5,  2) 

Actual  units  of 

delivered 

documentation 

are  compared  to  the  estimates 
documented  in  the  software 
development  plan.  (L2-35,  A5,  3) 

Actual  use  of  the 
project’s  critical 
computer  resources 

□  is  tracked.  (L2-36,  A7,  1) 

□  is  compared  to  the  estimates  for 
each  major  software  component 
as  documented  in  the  software 
development  plan.  (L2-36,  A7, 

1) 

Approved  changes  to 
commitments  that 
affect  the  software 
project 

are  communicated  to  the  members  of 
the  software  engineering  group  and 
other  software-related  groups.  (L2- 
35,  A4) 

Changes  in  estimates 
of  critical  computer 
resources  that  affect 
software 
commitments 

□  are  negotiated  with  the  affected 
groups.  (L2-37,  A7,  2) 

□  are  documented.  (L2-37,  A7,  2) 

Changes  in  size 
estimates  of  the 
software  work 
products  that  affect 
software 
commitments 

□  are  negotiated  with  the  affected 
groups.  (L2-36,  A5,  5) 

□  are  documented.  (L2-36,  A5,  5) 
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SPTO  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 
previous  page. 


Output 

State 

References 

Changes  in  staffing 
and  other  software 
costs  that  affect 
software 
commitments 

□  are  negotiated  with  the  affected 
groups.  (L2-36,  A6,  4) 

□  are  documented.  (L2-36,  A6,  4) 

Changes  to 
commitments  made 
to  individuals  and 
groups  external  to 
the  organization 

are  reviewed  with  senior 
management  according  to  a 
documented  procedure.  (L2-35,  A3) 

Changes  to  the 

software 

commitments 

are  made  with  the  involvement  and 
agreement  of  the  affected  groups. 
(L2-30,  C2,  4) 

Conflicts  and  issues 
(not  resolvable  at 
lower  levels) 

□  are  addressed  (during  reviews 
with  senior  management).  L2- 

40,  VI,  2) 

□  are  addressed  (during  reviews 
with  the  project  manager).  (L2- 

41, V2,  2).  (L2-40,  Vl,5) 

Contingencies  for  the 
(software)  risks 

are  adjusted  as  additional 
information  becomes  available.  (L2- 
38,  AlO,  1) 

Corrective  actions 

are  taken  when  the  software  plan  is 
not  being  achieved,  either  by 
adjusting  performance  or  by 
adjusting  the  plans.  (L2-30,  C2,  3) 

Effects  of  late  and 
early  completion  of 
software  activities, 
milestones,  and  other 
commitments 

are  evaluated  for  impacts  on  future 
activities  and  milestones.  (L2-37, 

A8,  2) 

Effort  and  staffing 

are  compared  to  the  estimates 
documented  in  the  software 
development  plan.  (L2-36,  A6,  3) 

High-risk  areas 

are  reviewed  with  the  project 
manager  on  a  regular  basis.  (L2-38, 
AlO,  1) 
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SPTO  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

Measurements  (to 
determine  the  status 
of  the  software 
tracking  and 
oversight  activities) 

□  are  made.  (L2-39,  Ml) 

□  are  used.  (L2-39,  Ml) 

Overall  projected  size 
of  the  software  work 
products  (estimates 
combined  with 
actuals) 

is  refined,  monitored,  and  adjusted 
on  a  regular  basis.  (L2-35,  A5,  4) 

Performance  (cost) 

□  is  reviewed  (during  reviews  with 
senior  management).  L2-40, 

VI,  1) 

□  is  reviewed  against  the  software 
development  plan  (during 
reviews  with  the  project 
manager).  (L2-41,  V2,  2) 

Performance 

(schedule) 

□  is  reviewed  (during  reviews  with 
senior  management).  L2-40, 

VI.  1) 

□  is  reviewed  against  t*"  software 
development  plan  (du,.  j 
reviews  with  the  project 
manager).  (L2-41,  V2,  2) 

Performance 

(staffing) 

□  is  reviewed  (during  reviews  with 
senior  management).  L2-40, 

VI.  1) 

□  is  reviewed  against  the  software 
development  plan  (during 
reviews  with  the  project 
manager).  (L2-41,  V2,  2) 

Performance 

(technical) 

□  is  reviewed  (during  reviews  with 
senior  management).  L2-40, 

VI.  1) 

□  is  reviewed  against  the  software 
development  plan  (during 
reviews  with  the  project 
manager).  (L2-41,  V2,  2) 
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SPTO  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

Priorities  of  the 
(software)  risks 

are  adjusted  as  additional 
information  becomes  available.  (L2- 
38,  AlO,  1) 

Problem  reports 

are  tracked  to  closure.  (L2'37,  A9, 

4) 

Problems  identified 
in  any  of  the  software 
work  products 

□  are  reported.  (L2-37,  A9,  3) 

□  are  documented.  (L2-37,  A9,  3) 

Project's  critical 
computer  resources 

are  tracked,  and  corrective  actions 
are  taken  as  necessary.  (L2-36,  A7) 

Project's  software 
costs 

are  tracked,  and  corrective  actions 
are  taken  as  necessary.  (L2-36,  A6) 

Project's  software 
effort 

is  tracked,  and  corrective  actions  are 
taken  as  necessary.  (L2-36,  A6) 

Project's  software 
schedule 

is  tracked,  and  corrective  actions  are 
taken  as  necessary.  (L2-37,  A8) 

Projected  use  of  the 
project's  critical 
computer  resources 

□  is  tracked.  (L2-36,  A7,  1) 

□  is  compared  to  the  estimates  for 
each  major  software  component 
as  documented  in  the  software 
development  plan.,  (L2-36,  A7, 

1) 

Results  of  SQA 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  software  project 
tracking  and 
oversight 

are  reported.  (L2-41,  V3) 

Size  of  the  changes 
to  the  software  work 
products 

is  tracked,  and  corrective  actions  are 
taken  as  necessary.  (L2-35,  A5) 

Size  of  the  software 
work  products 

is  tracked,  and  corrective  actions  are 
taken  as  necessary.  (L2-35,  A5) 

Sizes  for  all  major 
software  work 
products 

are  tracked,  and  corrective  actions 
are  taken  as  necessary.  (L2-35,  A5, 
Al) 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L2-Process-83 


SPTO  Process  -  Exit  Criteria,  Continued 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 

exit  criteria,  to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 

continued  previous  page. 


Output 

Sizes  of  the  changes 
to  all  major  software 
work  products 

Software  costs 


References 


are  tracked,  and  corrective  actions 
are  taken  as  necessary.  (L2-35,  A5, 
Al) _ 

□  are  tracked.  (L2-36,  A6,  2) 

□  are  compared  to  the  estimates 
documented  in  the  software 
development  plan.  (L2-36,  A6, 
2) 
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SPTO  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 
previous  page. 


Output 

State 

References 

Software 

development  plan 

□  is  documented.  (L2-33,  Al) 

□  is  used  for  tracking  the  software 
activities  and  communicating 
status.  (L2-33,  Al) 

□  is  updated  as  the  work  progresses 
to  reflect  accomplishments, 
particularly  when  milestones  are 
completed.  (L2-33,  Al,  1) 

□  is  readily  available  to:  (L2-33, 
A1.2) 

□  the  software  engineering 
group  (including  all 
subgroups,  such  as  software 
design), 

□  the  software  managers, 

□  the  project  manager, 

□  senior  management,  and 

□  other  affected  groups. 

□  is  revised  according  to  a 
documented  procedure.  (L2-33, 
A2) 

□  is  revised,  as  appropriate,  to 
incorporate  plan  refinements  and 
incorporate  plan  changes, 
particularly  when  plans  change 
significantly.  (L2-34,  A2,  1) 

□  is  updated  to  incorporate  all  new 
software  project  commitments 
and  changes  to  commitments. 
(L2-34,  A2,  2) 

□  is  reviewed  at  each  revision.  (L2- 
34,  A2,  3) 

□  is  managed  and  controlled.  (L2- 
34,  A2,  4) 

Software  planning 
data 

are  archived  for  use  by  ongoing  and 
future  projects.  (L2-38,  All,  3) 
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SPTO  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

Software  project 
commitments  made 
to  individuals  and 
groups  external  to 
the  organization 

are  reviewed  with  senior 
management  according  to  a 
documented  procedure.  (L2-35,  A3) 

Software  project  risks 

□  are  addressed  (during  reviews 
with  senior  management).  L2- 

40,  VI.  3) 

□  are  addressed  (during  reviews 
with  the  project  manager).  (L2- 

41, V2.  6).  (L2-40,  Vl,5) 

Software  release 
contents  for 
successive  builds 

are  compared  to  the  plans 
documented  in  the  software 
development  plan.  (L2-37,  A9,  2) 

Software  risks 
associated  with  cost 
aspects  of  the  project 

are  tracked.  (L2-37,  AlO) 

Software  risks 
associated  with 
resource  aspects  of 
the  project 

are  tracked.  (L2-37,  AlO) 

Software  risks 
associated  with 
schedule  aspects  of 
the  project 

ire  tracked.  (L2-37,  AlO) 

Software  risks 
associated  with 
technical  aspects  of 
the  project 

are  tracked..  (L2-37,  AlO) 

Software  schedule 
revisions  that  affect 
software 
commitments 

□  are  negotiated  with  the  affected 
groups.  (L2  37,  A8,  3) 

□  are  documented.  (L2-37,  A8,  3) 

Summary  status 
report  (from  each 
review  with  senior 
management) 

□  is  prepared.  (L2-40,  VI,  5) 

□  is  distributed  to  the  affected 
groups.  (L2-40,  Vl,5) 

Jonti  tucd  on  next  page 
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SPTO  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  project  tracking  and  oversight  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

Summary  status 
report  (from  each 
review  with  the 
project  manager) 

□  is  prepared.  (L2-41,  V2,  8) 

□  is  distributed  to  the  affected 
groups.  (L2-41,  V2,  8) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  project  tracking  and  oversight  process. 


Condition 

References 

The  project  manager  is  kept  informed  of  the  software 
project’s  status  and  issues.  (L2-30,  C2,  2) 

Senior  management  reviews  all  commitment  changes  and 
new  software  project  commitments  made  to  iiidividuals  and 
groups  external  to  the  organization.  (L2-31,  C2,  5) 

Software  engineering  technical  activities  are  tracked,  and 
corrective  actions  are  taken  as  necessary.  (L2-37,  A9) 

Members  of  the  software  engineering  group  report  their 
technical  status  to  their  first-line  manager  on  a  regular  basis. 
(L2-37,  A9,  1) 

The  software  engineering  group  conducts  periodic  internal 
reviews  tc  track  technical  progress,  plans,  performance,  and 
issues  against  the  software  development  plan.  (L2-38,  A12) 

Formal  reviews  to  address  the  accomplishments  and  results 
of  the  software  project  are  conducted  at  selected  project 
milestones  according  to  a  documented  procedure.  (L2-39, 
A13) 

The  activities  for  software  project  tracking  and  oversight  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L2- 
40,  VI) 

The  activities  for  software  project  tracking  and  oversight  are 
reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-41,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  project  tracking 
and  oversight  and  reports  the  results.  (L2-41,  V3) 

CMU/SEI-94-H3-1 
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SPTO  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  project 
tracking  and  oversight  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

Senior  management  reviews  all 
commitment  changes  and  new  software 
project  commitments  made  to  individuals 
and  groups  external  to  the  organization. 
(L2-31,  C2,  5) 

Senior 

management 

The  software  development  plan  is  reviewed 
at  each  revision.  (L2-34,  A2,  3) 

Not  specified  in 
CMM 

Software  project  commitments  and  changes 
to  commitments  made  to  individuals  and 
groups  external  to  the  organization  are 
reviewed  with  senior  management 
according  to  a  documented  procedure. 
(L2-35,  A3) 

Senior 

management 

High-risk  areas  are  reviewed  with  the 
project  manager  on  a  regular  basis.  (L2- 
38,  AlO,  2) 

Project 

manager 

I 

The  software  engineering  group  conducts 
periodic  internal  reviews  to  track  technical 
progress,  plans,  performance,  and  issues 
against  the  software  development  plan. 
(L2-38,  A 1 2) 

These  reviews  are  conducted  between: 

□  The  first-line  software  managers  and 
their  software  task  leaders. 

□  The  project  software  manager,  first- 
line  software  managers,  and  other 
software  managers,  as  appropriate. 

Software 

engineering 

group 

First-line 

software 

managers 

Project 

software 

manager 

Software 

managers 

Software  task 
leaders 

Continued  on  next  page 
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SPTO  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  project 
tracking  and  oversight  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

1 

Formal  reviews  to  address  the 
accomplishments  and  results  of  the 
software  project  are  conducted  at  selected 
project  milestones  according  to  a 
documented  procedure.  (L2-39,  A 13) 

These  reviews; 

□  Are  planned  to  occur  at  meaningful 
points  in  the  software  project's 
schedule,  such  as  the  beginning  or 
completion  of  selected  stages. 

□  Are  conducted  with  the  customer,  end 
user,  and  affected  groups  within  the 
organization,  as  appropriate. 

□  Use  materials  that  are  reviewed  and 
approved  by  the  responsible  software 
managers. 

□  Address  the  commitments,  plans,  and 
status  of  the  software  activities. 

□  Result  in  the  identification  and 
documentation  of  significant  issues, 
action  items,  and  decisions. 

□  Address  the  software  project  risks. 

□  Result  in  the  refinement  of  the  software 
development  plan  as  nece,ssary. 

Customer 

End  user 

Software 

managers 

Affected 

groups 

The  activities  for  software  project  tracking 
and  oversight  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2-40, 
VI) 

□  The  technical,  co.st,  .staffing,  and 
schedule  performance  are  reviewed. 

□  Conflicts  and  issues  not  re.solvable  at 
lower  levels  are  addressed. 

□  Software  project  risks  are  addressed. 

□  Action  items  are  a.s.signed,  reviewed, 
and  tracked  to  clo.sure. 

□  A  summary  status  report  from  each 
meeting  is  prepared  and  di.stributed  to 

the  affected  groups. 

-  — 

Senior 

management 

Affected 

groups 

Continued  on  next  page 
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SPTC  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


The  table  belcw  lists  the  recommended  reviews  and  audits  for  the  software  project 
tracking  and  oversight  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

I 

The  activities  for  software  project  tracking 

and  oversight  are  reviewed  with  the  project 

manager  on  both  a  periodic  and  event- 

driven  basis.  (L2-41,  V2) 

□  .\ffected  groups  are  represented. 

□  Tbe  technical,  cost,  staffing,  and 
schedule  performance  is  reviewed 
against  the  software  development  plan. 

□  Use  of  critical  computer  resources  is 
reviewed;  current  estimates  and  actual 
use  of  these  critical  computer  resources 
are  reported  against  the  original 
estimates. 

□  Dependencies  between  groups  are 
addressed. 

□  Conflicts  and  issues  not  resolvable  at 
lower  levels  are  addressed. 

□  Software  project  nsks  are  addressed. 

□  Action  items  are  assigned,  reviewed, 
and  tracked  to  closure. 

□  A  summary  report  from  each  meeting 
is  prepared  and  distributed  to  the 
affected  groups. 

Project 

manager 

Affected 

groups 

Continued  on  next  page 
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SPTO  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


CMU/SEI-94-  " 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  project 
tracking  and  oversight  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  project  tracking  and 
oversight  and  reports  the  results.  (L2-41, 
V3) 

At  a  minimum,  the  review’s  and/or  audits 
verify: 

□  The  activities  for  reviewing  and 
revising  commitments. 

□  The  activities  for  revising  the  software 
development  plan. 

□  The  content  of  the  revised  software 
development  plan. 

□  The  activities  for  tracking  the  software 
project's  cost,  schedule,  nsks,  technical 
and  design  constraints,  and 
functionality  and  performance. 

□  The  activities  for  conducting  the 
planned  technical  and  management 
reviews. 

SQA  group 

B-1 
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SPTO  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  managed  and 
controlled  during  the  software  project  tracking  and  oversight  process. 


V 

Work  Products  Managed  and  Controlled 

References 

Software  development  plan.  (L2-34,  A2,  4) 

J 

Software  replanning  data.  (L2-38,  All,  2) 
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SPTO  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software  project 
tracking  and  oversight  process. 


< 

Measurements 

References 

Actual  measurement  data  for  the  software  project.  (L2-38, 
All) 

Replanning  data  for  the  software  project.  (L2-38,  All) 

Measurements  to  determine  the  status  of  the  software 

tracking  and  oversight  activities.  (L2-39,  Ml) 

Examples  of  measurements  include: 

□  Effort  and  other  resources  expended  in  performing  the 
tracking  and  oversight  activities. 

□  Change  activity  for  the  software  development  plan, 
which  includes  changes  to  size  estimates  of  the  software 
work  products,  software  cost  estimates,  critical  computer 
resources  estimates,  and  schedule. 
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SPTO  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  software  process  tracking  and  oversight 
process  recommended  to  be  performed  according  to  a  documented  procedure. 


V 

Documented  procedures 

References 

The  project's  software  development  plan  is  revised  according 
to  a  documented  procedure.  {L2-33,  A2) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Software  project  commitments  and  changes  to  commitments 
made  to  individuals  and  groups  external  to  the 
organization  are  reviewed  with  senior  management 
according  to  a  documented  procedure.  (L2-35,  A3) 

Formal  reviews  to  address  the  accomplishments  and  results 
of  the  software  project  are  conducted  at  selected  project 
milestones  according  to  a  documented  procedure.  (L2-39, 
A13) 
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SPTO  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  project  tracking 
and  oversight  process. 


Training 

References 

The  software  managers  are  trained  in  managing  the 
technical  and  personnel  aspects  of  the  software  project.  (L2- 
32,  Ab4) 

_ I 

First-line  software  managers  receive  orientation  in  the 
technical  aspects  of  the  software  project.  (L2-32,  Ab5) 
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SPTO  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  software  project  tracking  and 
oversight  process. 


V 

Tools 

References 

_  1 

Tools  to  support  software  tracking.  (L2-32,  Ab3,  2) 
Examples  of  support  tools  include: 

□  spreadsheet  programs,  and 

□  project  planning/scheduling  programs. 
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Software  Subcontract  Management  (SSM)  Process 
SSM  Process  -  Overview 


SSM  process 
purpose 


SSM  process 
description 


The  purpose  of  Software  Subcontract  Management  is  to  select  qualified  software 
subcontractors  and  manage  them  effectively.  (L2-43) 


Software  Subcontract  Management  involves  selecting  a  software  subc'  ntractor, 
establishing  commitments  with  the  subcontractor,  and  tracking  and  reviewing  the 
subcontractor's  performance  and  results.  These  practices  cover  the  management  of 
a  software  (only)  subcontract,  as  well  as  the  management  of  the  software 
component  of  a  subcontract  that  includes  software,  hardware,  and  possibly  other 
system  components. 

The  subcontractor  is  selected  based  on  its  ability  to  perform  the  work.  Many 
factors  contribute  to  the  decision  to  subcontract  a  portion  of  the  prime  contractor's 
work.  Subcontractors  may  be  selected  based  on  strategic  business  alliances,  as  well 
as  technical  considerations.  The  practices  of  this  key  process  area  address  the 
traditional  acquisition  process  associated  with  subcontracting  a  defined  portion  of 
the  work  to  another  organization. 

When  subcontracting,  a  documented  agreement  covering  the  technical  and 
nontechnical  (e.g.,  delivery  dates)  requirements  is  established  and  is  used  as  the 
basis  for  managing  the  subcontract.  The  work  to  be  done  by  the  subcontractor 
and  the  plans  for  the  work  are  documented.  The  standards  that  are  to  be  followed 
by  the  subcontractor  are  compatible  with  the  prime  contractor's  standards. 

The  software  planning,  tracking,  and  oversight  activities  for  the  subcontracted  work 
are  performed  by  the  subcontractor.  The  prime  contractor  ensures  that  these 
planning,  tracking,  and  oversight  activities  are  performed  appropriately  and  that 
the  software  products  delivered  by  the  subcontractor  satisfy  their  acceptance 
criteria.  The  prime  contractor  works  with  the  subcontractor  to  manage  their 
product  and  process  interfaces.  (L2-43) 
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SSM  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L2-Process-99 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L2-Process-106 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L2-Process-107 

Activities 

Description  of  the  activities  of  the 
process. 

L2-Process-I09 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L2-Process-l  1 1 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L2-Process-l  13 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L2-Process-l  19 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L2-Process-124 

Measurements 

Description  of  process  measurements. 

L2-Process-125 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L2-Process-126 

Training 

List  of  training. 

L2-Process-l27 

Tools 

List  of  tools. 

L2-Process-128 
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SSM  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  subcontract  management  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

(parties) 

□  Changes  to  the  software  subcontractor's 
statement  of  work,  subcontract  terms 
and  conditions,  and  other  commitments 
are  resolved  according  to  a 
documented  procedure.  (L2-51,  A6) 

□  This  procedure  typically  specifies 
that  all  aR'ected  groups  of  both  the 
prime  contractor  and  the 
subcontractor  are  involved. 

□  The  subcontract  manager  is  responsible 
for  coordinating  the  technical  scope  of 
work  to  be  subcontracted  and  the  terms 
and  conditions  of  the  subcontract  with 
the  affected  parties.  (L2-45,  C2,  2) 

Customers 

The  subcontractor  is  provided  with 
visibility  of  the  needs  and  desires  of  the 
product's  customers  and  end  users,  as 
appropriate.  (L2-52,  A7,  1) 

End  users 

The  subcontractor  is  provided  with 
visibility  of  the  needs  and  desires  of  the 
product's  customers  and  end  users,  as 
appropriate.  (L2-52,  A7,  1) 

Individuals 

□  The  subcontract  manager  is 
knowledgeable  and  experienced  in 
software  engineering  or  has  individuals 
assigned  who  have  that  knowledge  and 
experience.  (L2-45,  C2,  1) 

□  Software  managers  and  other 

individuals  are  assigned  ecific 
responsibilities  for  man  jg  the 

subcontract.  (L2-46,  Abl,  1) 

□  Software  managers  and  other 
individuals  who  a;  c  involved  in 
establishing  and  managing  the  software 
subcontract  are  trained  to  perform 
these  activities.  (L2-46,  Ab2) 

□  Software  managers  and  other 
individuals  who  are  involved  in 
managing  the  software  subcontract 
receive  orientation  in  the  technical 
a.spects  of  the  subcontract.  (L2-46. 
Ab3) 
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SSM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  subcontract  management  process,  continued  from  the  previous  page. 


v/ 

Role 

Activities  Participated  in... 

Reference 

i 

Prime 

contractor 

□  Changes  to  the  subcontract  are  made 
with  the  involvement  and  agreement  of 
both  the  prime  contractor  and  the 
subcontractor.  (L2-45,  Cl,  3) 

□  The  contractual  agreement  between  the 
prime  contractor  and  the  software 
subcontractor  is  used  as  the  basis  for 
managing  the  subcontract.  (L2-50,A3) 

□  A  documented  subcontractor's  software 
development  plan  is  reviewed  and 
approved  by  the  prime  contractor. 
(L2-5I,  A4) 

□  Critical  dependencies  and  commitments 
between  the  prime  contractor  and  the 
subcontractor  are  addressed.  (L2-52, 
A7,  5) 

□  Subcontractor  commitments  to  the 
prime  contractor  and  prime 
contractor  commitments  to  the 
subcontractor  are  both  reviewed. 

□  The  prime  contractor  and  the 
subcontractor  coordinate  their  activities 
on  matters  relating  to  software 
configuration  management  to  ensure 
that  the  subcontractor's  pioducts  can  be 
readily  integrated  or  incorporated  into 
the  project  environment  of  the  prime 
contractor.  (L2-54,  A1 1,  2) 

□  The  prime  contractor  conducts 
acceptance  testing  as  part  of  the 
delivery  of  the  subcontractor's  software 
products  according  to  a  documented 
procedure.  (L2-55,  A 12) 

□  The  acceptance  procedures  and 
acceptance  criteria  for  each  product  are 
defined,  reviewed,  and  approved  by 
both  the  prime  contractor  and  the 
subcontractor  prior  to  the  acceptance 
test.  (L2-55,  A 12,  1) 
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SSM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  subcontract  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Prime 
contractor's 
SCM  group 

The  prime  contractor's  software 
configuration  management  group 

monitors  the  subcontractor’s  activities  for 
software  configuration  management 
according  to  a  documented  procedure. 
(L2-54,  All) 

Prime 
contractor's 
SQA  group  or 
SQA  group 

□  The  prime  contractor's  software 
quality  assurance  group  monitors  the 
subcontractor  s  software  quality 
assurance  activities  according  to  a 
documented  procedure.  (L2-53,  AlO) 

□  The  prime  contractor's  software 
quality  assurance  group  spot  checks 
the  subcontractor’s  software 
engineering  activities  and  products. 
(L2-54,  AlO,  2.1) 

□  The  prime  contractor's  software 
quality  assurance  group  audits  the 
subcontractor’s  software  quality 
assurance  records,  as  appropriate.  (L2- 
54,  AlO,  2.2) 

□  The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and. 
work  products  for  managing  the 
software  subcontract  and  reports  the 
results.  (L2-57,  V3) 

Prime 

contractor's 

management 

The  prime  contractor's  management 
conducts  periodic  slatus/coordination 
reviews  with  the  software  subcontractor’s 
management.  (L2-51,  A7) 

Project 

manager 

The  activities  for  managing  the  software 
subcontract  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L2-56,  V2) 
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SSM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  subcontract  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Senior 

management 

The  activities  for  managing  the  software 
subcontract  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2-56, 
VI) 

Software 

managers 

□  Software  managers  and  other 
individuals  are  assigned  specific 
responsibilities  for  managing  the 
subcontract.  (L2-46,  Abl,  1) 

□  Software  managers  and  other 
individuals  who  are  involved  in 
establishing  and  managing  the  software 
subcontract  are  trained  to  perform 
these  activities.  (L2-46,  Ab2) 

□  Software  managers  and  other 
individuals  who  are  involved  in 
managing  the  software  subcontract 
receive  orientation  in  the  technical 
aspects  of  the  subcontract.  (L2-46, 

Ab3) 

Software  sub¬ 
contractor's 
management 

The  prime  contractor’s  management 
conducts  periodic  status/coordination 
reviews  with  the  software  subcontractor's 
management.  (L2-51,  A7) 

Subcontract 

bidder 

The  software  subcontractor  is  selected, 
based  on  an  evaluation  of  the  subcontract 
bidders'  ability  to  perform  the  work, 
according  to  a  documented  procedure. 
(L2-49,  A2) 

Continued  on  next  page 
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SSM  Process  -  Roles,  continued 


Roles,  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

continued  software  subcontract  itianagement  process,  continued  from  the  previous  page. 


7 

Role 

Activities  Participated  in... 

Reference 

Subcontract 

manager 

□  A  subcontract  manager  is  designated 
to  be  responsible  for  establishing  and 
managing  the  software  subcontract. 
(L2-45,  C2) 

□  The  subcontract  manager  is 
knowledgeable  and  experienced  in 
software  engineering  or  has  individuals 
assigned  who  have  that  knowledge  and 
experience.  (L2-45,  C2,  1 ) 

□  The  subcontract  manager  is 
responsible  for  coordinating  the 
technical  scope  of  work  to  be 
subcontracted  and  the  terms  and 
conditions  of  the  subcontract  with  the 
affected  parties.  (L2-45,  C2,  2) 

□  The  subcontract  manager  is 
responsible  for:  (L2-45,  C2,  3) 

□  selecting  the  software 
subcontractor, 

□  managing  the  software  subcontract, 
and 

□  arranging  for  the  post-subcontract 
support  of  the  subcontracted 
products. 

Continued  on  next  page 
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SSM  Process  -  Roles,  continued 


Roies, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
softwar.  subcontract  management  process,  continued  from  the  previous  page. 


Tl 

Role 

Activities  Participated  in... 

Reference 

Software 

subcontractor 

□  Changes  to  the  subcontract  are  made 
with  the  involvement  and  agreement  of 
both  the  prime  contractor  and  the 
subcontractor.  (L2-45,  Cl,  3) 

□  The  software  subcontractor  is  selected, 
based  on  an  evaluation  of  the 
subcontract  bidders'  ability  to  perform 
the  work,  according  to  a  documented 
procedure.  (L2-49,  A2) 

□  The  contractual  agreement  between  the 
prime  contractor  and  the  software 
subcontractor  is  used  as  the  basis  for 
managing  the  subcontract.  (L2-50, 

A3) 

□  The  subcontractor  is  provided  with 
visibility  of  the  needs  and  desires  of  the 
product's  customers  and  end  users,  as 
appropriate.  (L2-52,  A7,  I) 

□  Critical  dependencies  and  commitments 
between  the  prime  contractor  and  the 
subcontractor  are  addressed.  (L2-52, 
A7,  5) 

□  Subcontractor  commitments  to  the 
prime  contractor  and  prime 
contractor  commitments  to  the 
subcontractor  are  both  reviewed. 

□  Periodic  technical  reviews  and 
interchanges  are  held  with  the  software 
subcontractor.  (L2-52,  A8) 

□  The  prime  contractor  and  the 
subcontractor  coordinate  their 
activities  on  matters  relating  to  software 
configuration  management  to  ensure 
that  the  subcontractor's  products  can  be 
readily  integrated  or  incorporated  into 
the  project  environment  of  the  prime 
contractor.  (L2-54,  A1 1,  2) 

Role  continues  on  the  next  page 

Continued  on  next  page 
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SSM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  subcontract  management  process,  continued  from  the  previous  page. 


V  1  Role 

Activities  Participated  in... 

Reference 

Software 

subcontractor, 

continued 

□  The  acceptance  procedures  and 
acceptance  criteria  for  each  product  are 
defined,  reviewed,  and  approved  by 
both  the  prime  contractor  and  the 
subcontractor  prior  to  the  test.  (L2-55. 
A12.  1) 

□  The  software  subcontractor's 
performance  is  evaluated  on  a  periodic 
basis,  and  the  evaluation  is  reviewed 
with  the  subcontractor.  (L2-55,  A 13) 

Software 

subcontractor 

groups 

Critical  dependencies  and  commitments 
between  the  subcontractor’s  software 
engineering  group  and  other 
subcontractor  groups  are  addressed.  (L2- 
52,  A7,  4) 

Software  sub¬ 
contractor's 
software 
engineering 
group 

Critical  dependencies  and  commitments 
between  the  subcontractor’s  software 
engineering  group  and  other  subcontractor 
groups  are  addressed.  (L2-52,  A7,  4) 
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SSM  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  in  the  software  subcontract  management 
process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  subcontract  management  process. 


V 

Condition 

References 

The  project  follows  a  written  organizational  policy  for 
managing  the  software  subcontract.  (L2-44,  Cl) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  SSM  policy.] 

A  subcontract  manager  is  designated  to  be  responsible  for 
establishing  and  managing  the  software  subcontract.  (L2- 
45,  C2) 

The  subcontract  manager  is  knowledgeable  and 
experienced  in  software  engineering  or  has  individuals 
assigned  who  have  that  knowledge  and  experience.  (L2-45, 
C2,  1) 

Adequate  resources  and  funding  are  provided  for  selecting 
the  software  subcontractor  and  managing  the  subcontract. 
(L2-46,  Abl) 

Software  managers  and  other  individuals  are  assigned 
specific  responsibilities  for  managing  the  subcontract.  (L2- 
46,  Abl,  1) 

1 

Tools  to  support  managing  the  subcontract  are  made 
available.  (L2-46,  Abl,  2) 

Software  managers  and  other  individuals  who  are  involved 
in  establishing  and  managing  the  software  subcontract  are 
trained  to  perform  these  activities.  (L2-46,  Ab2) 

Software  managers  and  other  individuals  who  are  involved 
in  managing  the  software  subcontract  receive  orientation  in 
the  technical  aspects  of  the  subcontract.  (L2-46,  Ab3) 
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SSM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  subcontract 
management  process. 


V 

Input 

Org.  Input 

References 

Acceptance  procedures  and  acceptance 
criteria  for  each  product.  (L2-55,  A 12,  1) 

Computer  resources  designated  as  critical 
for  the  project.  (L2-52,  A7,  3) 

Conflicts  and  issues  not  resolvable  by  the 
subcontractor.  (L2-52,  A7,  8) 

Critical  dependencies  and  commitments 
between  the  prime  contractor  and  the 
subcontractor.  (L2-52,  A7,  5) 

Critical  dependencies  and  commitments 
between  the  subcontractor's  software 
engineering  group  and  other 
subcontractor  groups.  (L2-52,  A7,  4) 

Needs  and  desires  of  the  product's 
customers  and  end  users.  (L2-52,  A7,  1 ) 

Prior  performance  records  on  similar  work, 
if  available.  (L2-49,  A2,  2) 

Project  risks  involving  the  subcontractor's 
work.  (L2-.52,  A7.  7) 

Project's  software  development  plan.  (L2- 
47,  Al,2.4) 

Project's  software  requirements.  (L2-47, 

Al,  2.3) 

Project's  standards  and  procedures.  (L2- 
47,  Al,  2.5) 

Project's  statement  of  work.  (L2-47,  Al, 
2.1) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  a  statement  of 
work.] 

Project's  system  requirements  allocated  to 
software.  (L2-47,  Al,  2.2) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  system  requirements 
allocated  to  software.] 

Proposals  submitted  for  the  planned 
subcontract.  (L2-49,  A2,  1) 

Subcontracted  products.  (L2-45,  C2,  3.3) 

Continued  on  next  page 
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SSM  Process  -  Inputs,  Continued 


Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  software  subcontract 
management  process,  continued  from  the  previous  page. 


1 

s 

Input 

Org.  Input 

References 

Subcontractor's  cost  performance.  (L2-52, 
A7,  2) 

Subcontractor's  plans.  (L2-54,  A 10,  1) 

Subcontractor's  procedures.  (L2-54,  A 10, 

1) 

Subcontractor's  products.  (L2-54,  A 10, 

2.1) 

Subcontractor's  resources.  (L2-54,  AlO,  1) 

Subcontractor's  schedule  performance. 
(L2-52,  A7,  2) 

Subcontractor's  software  baseline  library. 
(L2-54,  All,  3) 

Subcontractor's  software  engineering 
accomplishments  and  results.  (L2-53,  A9) 

Subcontractor's  SQA  records.  (L2-54, 

AlO,  2.2) 

Subcontractor's  staffing  performance. 
(L2-52,  A7,  2) 

Subcontractor's  standards.  (L2-54,  AlO,  1) 

Subcontractor's  technical  performance. 
(L2-52,  A7,  2) 

Technical  and  nontechnical  characteristics 
of  the  project.  (L2-47,  Al,  !) 
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SSM  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  software  subcontract 
management  process. 


V 

Activities 

References 

The  work  to  be  subcontracted  is  defined  and  planned 
according  to  a  documented  procedure.  (L2-47,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  software  subcontractor  is  selected  based  on  an 
evaluation  of  the  subcontract  bidders'  ability  to  perform  the 
work,  according  to  a  documented  procedure.  (L2-49,  A2) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  contractual  agreement  between  the  prime  contractor 
and  the  software  subcontractor  is  used  as  the  basis  for 
managing  the  subcontract.  (L2-50,  A3) 

[  Refer  to  SPF  Standards  for  additional  information 
regarding  the  contractual  agreement.  ] 

A  documented  subcontractor's  software  development  plan  is 
reviewed  and  approved  by  the  prime  contractor.  (L2-51, 

A4) 

[Refer  to  SSM  Process  Reviews  and  Audits  for  additional 
information.] 

A  documented  and  approved  subcontractor's  software 
development  plan  is  used  for  tracking  the  software  activities 
and  communicating  status.  (L2-51,  A5) 

Changes  to  the  software  subcontractor's  statement  of  work, 
subcontract  terms  and  conditions,  and  other  commitments 
are  resolved  according  to  a  documented  procedure.  (L2-51, 
A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  prime  contractor's  management  conducts  periodic 
status/coordination  reviews  with  the  software  subcontractor's 
management.  (L2-51,A7) 

[Refer  to  SSM  Process  Reviews  and  Audits  for  additional 
information.] 

Periodic  technical  reviews  and  interchanges  are  held  with  the 
software  subcontractor.  (L2-52,  A8) 

[Refer  to  SSM  Process  Reviews  and  Audits  for  additional 
information.] 

Continued  on  next  page 
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SSM  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  subcontract 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

Formal  reviews  to  address  the  subcontractor's  software 
engineering  accomplishments  and  results  are  conducted  at 
selected  milestones  according  to  a  documented  procedure. 
(L2-53.  A9) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  prime  contractor's  software  quality  assurance  group 
monitors  the  subcontractor's  software  quality  assurance 
activities  according  to  a  documented  procedure.  (L2-53, 
AlO) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  prime  contractor's  software  configuration 
management  group  monitors  the  subcontractor's  activities 
for  software  configuration  management  according  to  a 
documented  procedure.  (L2-54,  All) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  prime  contractor  conducts  acceptance  testing  as  part  of 
the  delivery  of  the  subcontractor's  software  products 
according  to  a  documented  procedure.  (L2'55,  A 12) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Tlie  software  subcontractor's  performance  is  evaluated  on  a 
periodic  basis,  and  the  evaluation  is  reviewed  with  the 
subcontractor.  (L2-55,  A 13) 

Measurements  are  made  and  used  to  determine  the  status  of 
the  activities  for  managing  the  software  subcontract.  (L2-55, 
Ml) 

The  activities  for  managing  the  software  subcontract  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L2- 
56,  VI) 

The  activities  for  managing  the  software  subcontract  are 
reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-56,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  managing  the  software 
subcontract  and  reports  the  results.  (L2-57,  V3) 

[Refer  to  SSM  Process  Reviews  and  Audits  for  additional 
information.] 
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SSM  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  software 
subcontract  management  process. 


V 

Oucput 

Org.  Output 

References 

Acceptance  criteria  for  each  product.  (L2- 
55,  A12,  I) 

Acceptance  procedures  for  each  product. 
(L2-55,  A 12,  1) 

Action  items  resulting  from  periodic 
status/coordination  reviews  with  the 
software  subcontractor's  management. 
(L2-52,  A7,  9) 

1 

Action  plan  for  any  software  product  that 
does  not  pass  its  acceptance  test.  (L2-55, 
A12,  3) 

Changes  to  the  software  subcontractor's 
statement  of  work.  (L2-51,  A6) 

Changes  to  the  subcontract  terms  and 
conditions.  (L2-5 1 ,  A6) 

Changes  to  the  subcontract.  (L2-45,  Cl,  3) 

Contractual  agreements.  (L2-45,  Cl,  2) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  contractual 
agreements.] 

Evaluation  of  the  subcontract  bidders' 
ability  to  perform  the  work.  (L2-49,  A2) 

Functions  or  subsystems  to  be 
subcontracted.  (L2-47,  Al,  1.1) 

List  of  dependencies  between  the 
subcontractor  and  the  prime  contractor. 
(L2-50,  A3,  4) 

Measurements  (to  determine  the  status  of 
the  activities  for  managing  the  software 
subcontract).  (L2-55,  MI) 

Nonconformance  to  the  subcontract.  (L2- 
52,  Al,  6) 

Plan  for  selecting  a  subcontractor.  (L2- 
48,  Al,4) 

Requirements  for  the  products  to  be 
developed  (by  the  subcontractor).  (L2-50, 
A3,  3) 

Continued  on  next  page 
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SSM  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


V 

Output 

Org.  Output 

References 

Results  of  the  acceptance  tests.  (L2-55, 

A12,  2) 

Significant  issues,  action  items,  and 
decisions  resulting  from  formal  reviews  of 
the  subcontractor's  software  engineering 
accomplishments.  (L2-53,  A9,  3) 

Software  products  and  activities  to  be 
subcontracted.  (L2-47,  Al,  i) 

Software  risks.  (L2-53,  A9,  4) 

Specification  of  the  software  products  and 
activities  to  be  subcontracted.  (L2-47,  Al, 
1.2) 

Specification  of  work  to  be  subcontracted. 
(L2-47,  Al,  2) 

Subcontract  statement  of  work.  (L2-47, 
Al,3) 

Subcontractor’s  software  development 
plan.  (L2-51,  A4) 

Work  to  be  subcontracted.  (L2-47,  Al) 
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SSM  Process  -  Exit  Criteria 


Output'based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  subcontract  management  process. 


V  Output 

State 

References 

Acceptance  criteria 
for  each  product 

□  are  defined  by  both  the  prime 
contractor  and  the 
subcontractor  prior  to 
acceptance  testing.  (L2-55,  A 12, 
1) 

□  are  reviewed  by  both  the  prime 
contractor  and  the 
subcontractor  prior  to 
acceptance  testing.  (L2-55,  A 12, 
1) 

□  are  approved  by  both  the  prime 
contractor  and  the 
subcontractor  prior  to 
acceptance  testing.  (L2-55,  A 12, 
1) 

Acceptance 
procedures  for  each 
product 

□  are  defined  by  both  the  prime 
contractor  and  the 
subcontractor  prior  to 
acceptance  testing.  (L2-55,  A12, 
1) 

□  are  reviewed  by  both  the  prime 
contractor  and  the 
subcontractor  prior  to 
acceptance  testing.  (L2-55,  A 12, 
1) 

□  are  approved  by  both  the  prime 
contractor  and  the 
subcontractor  prior  to 
acceptance  testing.  (L2-55,  A12, 
1) 

Action  items 
resulting  from 
periodic 

status/coordination 
reviews  with  the 
software 
subcontractor's 
management 

□  are  assigned.  (L2-52,  A7,  9) 

□  are  reviewed.  (L2-52,  A7,  9) 

□  are  tracked  to  closure.  (L2-52, 
A7,  9) 

Continued  on  next  page 
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SSM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  subcontract  management  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Action  plan  for  any 
software  product  that 
does  not  pass  its 
acceptance  test 

is  established.  (L2-55,  A 12,  3) 

Changes  to  the 
software 
subcontractor's 
statement  of  work 

are  resolved  according  to  a 
documented  procedure.  (L2-51,  A6) 

Changes  to  the 
software  subcontract 
terms  and  conditions 
and  other 
commitments 

are  resolved  according  to  a 
documented  procedure.  (L2-51,  A6) 

Changes  to  the 
subcontract 

are  made  with  the  involvement  and 
agreement  of  both  the  prime 
contractor  and  the  subcontractor. 
(L2-45,  Cl.  3) 

Contractual 

agreement(s) 

form  the  basis  for  managing  the 
subcontract.  (L2-45,  Cl,2) 

Functions  or 
subsystems  to  be 
subcontracted 

are  selected  to  match  the  skills  and 
capabilities  of  potential 
subcontractors.  (L2-47,  Al,  1.1) 

Measurements  (to 
determine  the  status 
of  the  activities  for 
managing  the 
software  subcontract) 

□  are  made.  (L2-55,  Ml) 

□  are  used.  {L2-55,  Ml) 

Nonconformance  to 
the  subcontract 

is  addressed.  (L2-52,  A7,  6) 

Plan  for  selecting  a 
subcontractor 

□  is  prepared  concurrent  with  the 
subcontract  .'‘atement  of  work. 
(L2-48,  Al,  4) 

□  is  reviewed,  as  appropriate.  (L2- 
48,  Al,4) 

Results  of  the 
acceptance  tests 

are  documented.  (L2-55,  A 12,  2) 
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SSM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  subcontract  management  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Significant  issues, 
action  items,  and 
decisions  resulting 
from  formal  reviews 
of  the  subcontractor's 
software  engineering 
accomplishments 

□  are  identified.  (L2-53,  A9,  3) 

□  are  documented.  (L2-53,  A9,  3) 

Software  products 
and  activities  to  be 
subcontracted 

are  selected  based  on  a  balanced 
assessment  of  both  technical  and 
nontechnical  characteristics  of  the 
project.  (L2-47,  Al,  1) 

Specification  of  the 
software  products 
and  activities  to  be 
subcontracted 

is  determined  based  on  a  systematic 
analysis  and  appropriate  partitioning 
of  the  system  and  software 
requirements.  (L2-47,  Al,  1.2) 

Specification  of  work 
to  be  subcontracted 

is  derived  from  the  project’s:  (L2- 
47,  Al,2) 

□  statement  of  work, 

□  system  requirements  allocated  to 
software, 

□  software  requirements, 

□  software  development  plan,  and 

□  software  standards  and 
procedures. 

Subcontract 
statement  of  work 

is:  (L2-47,  Al,3) 

□  prepared, 

□  reviewed, 

□  agreed  to, 

□  revised  when  necessary,  and 

□  managed  and  controlled. 

Continued  on  next  page 
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SSM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  subcontract  management  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Subcontractor’s 
software  development 
plan 

□  is  documented.  (L2-5 1 ,  A4) 

□  is  reviewed  and  approved  by  the 
prime  contractor.  (L2-51,  A4) 

□  covers  (directly  or  by  reference) 
the  appropriate  items  from  the 
prime  contractor's  software 
development  plan.  (L2-5 1 ,  A4, 

1) 

□  is  used  for  tracking  the  software 
activities  and  communicating 
status.  (L2-51,  A5) 

□  is  refined,  as  appropriate.  (L2- 
53,  A9,  5) 

Work  to  be 
subcontracted 

is  defined  and  planned  according  to 
a  documented  procedure.  (L2-47, 
Al) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  subcontract  management  process. 


V 

Condition 

References 

Documented  standards  and  procedures  are  used  in  selecting 
software  subcontractors  and  managing  the  software 
subcontracts.  (L2-45,  Cl,l) 

The  software  subcontractor  is  selected  based  on  an 
evaluation  of  the  subcontract  bidders'  ability  to  perform  the 
work,  according  to  a  documented  procedure.  (L2-49,  A2) 

Continued  on  next  page 
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SSM  Process  -  Exit  Criteria,  continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  subcontract  management  process,  continued  from  the  previous 
page. 


< 

Condition 

References 

The  prime  contractor’s  management  conducts  periodic 

status/coordination  reviews  with  the  software  subcontractor's 

management.  (L2-51,A7) 

□  The  subcontractor  is  provided  with  visibility  of  the 
needs  and  desires  of  the  product's  customers  and  end 
users,  as  appropriate. 

□  The  subcontractor's  technical,  cost,  staffing,  and  schedule 
performance  is  reviewed  against  the  subcontractor's 
software  development  plan. 

□  Computer  resources  designated  as  critical  for  the  project 
are  reviewed;  the  subcontractor's  contribution  to  the 
current  estimates  are  tracked  and  compared  to  the 
estimates  for  each  software  component  as  documented  in 
the  subcontractor's  software  development  plan. 

□  Critical  dependencies  and  commitments  between  the 
subcontractor's  software  engineering  group  and  other 
subcontractor  groups  are  addressed. 

□  Critical  dependencies  and  commitments  between  the 
prime  contractor  and  the  subcontractor  are  addressed. 

□  Subcontractor  commitments  to  the  prime  contractor 
and  prime  contractor  commitments  to  the 
subcontractor  are  both  reviewed. 

□  Nonconformance  to  the  subcontract  is  addressed. 

□  Project  risks  involving  the  subcontractor's  work  are 
addressed. 

□  Conflicts  and  issues  not  resolvable  internally  by  the 
subcontractor  are  addressed. 

□  Action  items  are  assigned,  reviewed,  and  tracked  to 
closure. 

Periodic  technical  reviews  and  intercharges  are  held  with  the 
software  subcontractor.  (L2-52,  A8) 

Formal  reviews  to  address  the  subcontractor's  software 
engineering  accomplishments  and  results  are  conducted  at 
selected  milestones  according  to  a  documented  procedure. 
(L2-53,  A9) 

ont  •Hied  on  next  page 
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SSM  Process  -  Exit  Criteria,  Continued 


General  exit 

crite'-ia, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  subcontract  management  process,  continued  from  the  previous 
page. 


V 

Condition 

references 

The  prime  contractor's  software  quality  assurance  group 
monitors  the  subcontractor’s  software  nuality  assurance 
activities  according  to  a  documented  procedure.  (L2-53, 
AlO) 

The  prime  contractor's  software  configuration 
management  group  monitors  the  subcontractor's  activities 
for  software  configuration  management  according  to  a 
documented  procedure.  (L2-54,  All) 

The  prime  contractor  conducts  acceptance  testing  as  part  of 
the  delivery  of  the  subcontractor's  software  products 
according  to  a  documented  procedure.  (L2-5.‘^  '  1 2) 

The  software  subcontractor’s  performance  is  evai.  'ted  on  a 
periodic  basis,  and  the  evaluation  is  reviewed  v/ith  the 
subcontractor.  (L2-55,  A 13) 

The  activities  for  managing  the  software  subcontract  are 
reviewed  with  senior  management  on  a  periodic  basis  (L2- 
56,  V!) 

The  activities  for  managing  the  sofiware  subcontract  are 
reviewed  with  the  project  manager  on  both  a  periodic  ana 
event-driven  basis.  (L2-56,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  managing  the  software 
subcontract  and  reports  the  results.  (L2-57,  V3) 
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SSM  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
subcontract  management  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

A  documented  subcontractor's  software 
development  plan  is  reviewed  and 
approved  by  the  prime  contractor,  (L2- 
51,  A4) 

□  This  software  development  plan  covers 
(directly  or  by  reference)  the 
appropriate  items  from  the  prime 
contractor's  software  development  plan. 

Prime 

contractor 

The  prime  contractor's  management 
conducts  periodic  status/coordination 
reviews  with  the  software  subcontractor's 
management.  (L2-51,A7) 

□  The  subcontractor  is  provided  with 
visibility  of  the  needs  and  desires  of  the 
product's  customers  and  end  users,  as 
appropriate. 

□  The  subcontractor's  technical,  cost, 
staffing,  and  schedule  performance  is 
reviewed  against  the  subcontractor's 
software  development  plan. 

□  Computer  resources  designated  as 
critical  for  the  project  are  reviewed;  the 
subcontractor's  contribution  to  the 
current  estimates  are  tracked  and 
compared  to  the  estimates  for  each 
software  component  as  documented  in 
the  subcontractor's  software 
development  plan. 

□  Critical  dependencies  and 
commitments  between  the 
subcontractor's  software  engineering 
group  and  other  subcontractor  groups 
are  addressed. 

Prime 

contractor's 

management 

Software  sub¬ 
contractor's 
management 

Subcontractor 

Sub¬ 

contractor's 

software 

engineering 

group 

Subcontractor 

groups 

Review  continues  on  the  next  page 

Continued  on  next  page 
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SSM  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review  I 
Participants  | 

References 

Review  continued  from  previous  page 

□ 

Critical  dependencies  and 
commitments  between  the  prime 
contractor  and  the  subcontractor  are 
addressed. 

Prime 

contractor 

Subcontractor 

□  Subcontractor  commitments  to  the 
prime  contractor  and  prime 
contractor  commitments  to  the 
subcontractor  are  both  reviewed. 

□ 

Nonconformance  to  the  subcontract  is 
addressed. 

□ 

Project  risks  involving  the 
subcontractor's  work  are  addressed. 

□ 

Conflicts  and  issues  not  resolvable 
internally  by  the  subcontractor  are 
addressed. 

□ 

Action  items  are  assigned,  reviewed, 
and  tracked  to  closure. 

Periodic  technical  reviews  and  interchanges 
are  held  with  the  software  subcontractor. 
(L2-52.  A8) 

These  reviews: 

Software 

subcontractor 

□ 

Provide  the  subcontractor  with 
visibility  of  the  customer’s  and  end 
users'  needs  and  desires,  as  appropriate. 

Subcontractor 

□ 

Monitor  the  subcontractor's  technical 
activities. 

□ 

Verify  that  the  subcontractor’s 
interpretation  and  implementation  of 
the  technical  requirements  conform  to 
the  prime  contractor’s  requirements. 

□ 

Verify  that  commitments  are  being 
met. 

□ 

Verify  that  technical  issues  are  resolved 
in  a  timely  manner. 

Continued  on  next  page 
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SSM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

Formal  reviews  to  address  the 
subcontractor's  software  engineering 
accomplishments  and  results  are  conducted 
at  selected  milestones  according  to  a 
documented  procedure.  (L53,  A9) 

□  Reviews  are  preplanned  and 
documented  in  the  statement  of  work. 
(L53,  A9,  I) 

□  Reviews  address  the  subcontractor's 
commitments  for,  plans  for,  and  status 
of  the  software  activities.  (L2-53,  A9, 

2) 

Not  specified  in 
CMM 

The  prime  contractor’s  software  quality 
assurance  group  monitors  the 
subcontractor’s  software  quality 
assurance  activities  according  to  a 
documented  procedure.  (L2,  53,  A 10) 

□  The  subcontractor's  plans,  resources, 
procedures,  and  standards  for  software 
quality  assurance  are  periodically 
reviewed  to  ensure  they  are  adequate  to 
monitor  the  subcontractor’s 
performance.  (L2-54,  A 10,  1) 

Prime 
contractor's 
SQA  group 

Regular  reviews  of  the  subcontractor  are 
conducted  to  ensure  the  approved 
procedures  and  standards  are  being 
followed.  (L2-54,  A 10,  2) 

□  The  prime  contractor’s  software 
quality  assurance  group  spot  checks 
the  subcontractor's  software 
engineering  activities  and  products. 

□  The  prime  contractor’s  software 
quality  assurance  group  audits  the 
subcontractor's  software  quality 
assurance  records,  as  appropriate. 

Subcontractor 

Prime 
contractor’s 
SQA  group 

The  subcontractor's  records  of  its  software 
quality  assurance  activities  are  periodically 
audited  to  assess  how  well  the  software 
quality  assurance  plans,  standards,  and 
procedures  are  being  followed.  {L2-54, 
AlO,  3) 

Prime 
contractor’s 
SQA  group 

Continued  on  neM  page 


CMU/SEI-94-HB-1 


L2-Process-121 


SSM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
snbcontrac*  management  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

The  subcontractor's  plans,  resources, 
procedures,  and  standards  for  software 
configuration  management  are  reviewed  to 
ensure  they  are  adequate.  (L2-54,  All,  1 ) 

Prime 
contractor's 
SCM  group 

The  subcontractor's  software  baseline 
library  is  periodically  audited  to  assess  how 
well  the  standards  and  procedures  for 
software  configuration  management  are 
being  followed  and  how  effective  they  are 
in  managing  the  software  baseline.  (L2-54, 
All,  3) 

Prime 
contractor’s 
SCM  group 

1 

The  acceptance  procedures  and  acceptance 
criteria  for  each  product  are  defined, 
reviewed,  and  approved  by  both  the  prime 
contractor  and  the  subcontractor  prior  to 
the  test.  (L2-55,  A12,  1) 

Prime 

contractor 

Subcontractor 

The  software  subcontractor's  performance 
is  evaluated  on  a  periodic  basis,  and  the 
evaluation  is  reviewed  with  the 
subcontractor.  (L2-55,  A13) 

Subcontractor 

The  activities  for  managing  the  software 
subcontract  are  reviewed  with  senior 
.management  on  a  periodic  basis.  (L2-56, 
VI; 

Senior 

management 

The  activities  for  managing  the  software 
subcontract  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L2-56,  V2) 

Project 

manager 

Continued  on  next  page 
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SSM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  managing  the  software 
subcontract  and  reports  the  results.  (L2- 
57,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify: 

□  The  activities  for  selecting  the 
subcontractor. 

□  The  activities  for  managing  the 
software  subcontract. 

□  The  activities  for  coordinating 
configuration  management  activities  of 
the  prime  contractor  and 
subcontractor. 

□  The.  onduct  of  planned  reviews  with 
the  subcontractor. 

□  The  conduct  of  reviews  that  establish 
completion  of  key  project  milestones 
or  stages  for  the  subcontract. 

□  The  acceptance  process  for  the 
subcontra^'tor's  software  products. 

SQA  group 

CMU/SEI-94-HB-1 


L2-Process-123 


SSM  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  managed  and 
controlled  during  the  software  subcontract  management  process. 


Work  Products  Managed  and  Controlled 

References 

Subcontract  statement  of  work.  (L2-48,  Al,  3.5) 
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SSM  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software  subcontract 
management  process. 


Measurements 

References 

Measurements  are  made  and  used  to  determine  the  status  of 

the  activities  for  managing  the  software  subcontract.  (L2-55, 

Ml) 

Examples  of  measurements  include: 

□  Costs  of  the  activities  for  managing  the  subcontract 
compared  to  the  plan. 

□  Actual  delivery  dates  for  subcontracted  products 
compared  to  the  plan. 

□  Actual  dates  of  prime  contractor  deliveries  to  the 
subcontractor  compared  to  the  plan. 

1 
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SSM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  software  subcontract  management  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


V 

Documented  Procedure(s) 

References 

The  work  to  be  subcontracted  is  defined  and  planned 
according  to  a  documented  procedure.  (L2-47,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  software  subcontractor  is  selected  based  on  an 
evaluation  of  the  subcontract  bidders'  ability  to  perform  the 
work,  according  to  a  documented  procedure.  (L2-49,  A2) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Changes  to  the  software  subcontractor's  statement  of  work, 
subcontract  terms  and  conditions,  and  other  commitments 
are  resolved  according  to  a  documented  procedure.  (L2-51, 
A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Formal  reviews  to  address  the  subcontractor's  software 
engineering  accomplishments  and  results  are  conducted  at 
selected  milestones  according  to  a  documented  procedure. 
(L2-53,  A9) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  prime  contractor's  software  quality  assurance  grour 
monitors  the  subcontractor's  software  quality  assurance 
activities  according  to  a  documented  procedure..  (L2-53, 
AlO) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  prime  contractor's  software  configuration 
management  group  monitors  the  subcontractor's  activities 
for  software  configuralion  management  according  to  a 
documented  procedure.  (L2-54,  All) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  prime  contractor  conducts  acceptance  testing  as  part  of 
the  delivery  of  the  subcontractor’s  software  products 
according  to  a  documented  procedure.  (L2-55,  A 12) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 
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SSM  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  subcontract 
management  process. 


V 

Training 

References 

Software  managers  and  other  individuals  who  are  involved 
in  establishing  and  managing  the  software  subcontract  are 
trained  to  perform  these  activities.  (L2  46,  Ab2) 

Software  managers  and  other  individuals  who  are  involved 
in  managing  the  software  subcontract  receive  orientation  in 
the  technical  aspects  of  the  subcontract.  (L2-46,  Ab3) 
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SSM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  sortware  subcontract 
management  process. 


Tools 

References 

Tools  to  support  managing  the  subcontract.  (L2-46,  Abl,  2) 
Examples  of  support  tools  include: 

□  estimating  models, 

□  spreadsheet  programs,  and 

□  project  management  and  scheduling  programs. 

L2-Process-128 


CMU/SEI-94'HB-1 


Software  Quality  Assurance  (SQA)  Process 
SQA  Process  -  Overview 


SQA  process 
purpose 


SQA  process 
description 


The  purpose  of  Software  Quality  Assurance  is  to  provide  management  with 
appropriate  visibility  into  the  process  being  used  by  the  software  project  and  of  the 
products  being  built.  (L2-59) 


Software  Quality  Assurance  involves  reviewing  and  auditing  the  software  products 
and  activities  to  verif>  that  they  comply  with  the  applicable  procedures  and 
standards  and  providing  the  software  project  and  other  appropriate  managers  with 
the  results  of  these  reviews  and  audits. 

The  software  quality  assurance  group  works  with  the  software  project  during  its 
early  stages  to  establish  plans,  standards,  and  procedures  that  will  add  value  to  the 
software  project  and  satisfy  the  constraints  of  the  project  and  the  organization’s 
policies.  By  participating  in  establishing  the  plans,  standards,  and  procedures,  the 
software  quality  assurance  group  helps  ensure  they  fit  the  project's  needs  and 
verifies  that  they  will  be  usable  for  performing  reviews  and  audits  throughout  the 
software  life  cycle.  The  software  quality  assurance  group  reviews  project  activities 
and  audits  software  work  products  throughout  the  life  cycle  and  provides 
management  with  visibility  as  to  whether  the  software  project  is  adhering  to  its 
established  plans,  standards,  and  procedures. 

Compliance  issues  are  first  addressed  within  the  software  project  and  resolved  there 
if  possible.  For  issues  not  resolvable  within  the  software  project,  the  software 
quality  assurance  group  escalates  the  issue  to  an  appropriate  level  of  management 
for  resolution. 

This  key  process  area  covers  the  practices  for  the  group  performing  the  software 
quality  assurance  function.  The  practices  identifying  the  specific  activities  and 
work  products  that  the  software  quality  assurance  group  reviews  and/or  audits  are 
generally  contained  in  the  Verifying  Implementation  common  feature  of  the  other 
key  process  areas.  (L2-59) 


Continued  on  next  page 
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SQA  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L2-Process-I31 

Entry  Criteria 

Descriptio'i  of  when  the  process  can  start. 

L2-Process- 1 36 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L2-Process- 1 37 

Activities 

Description  of  the  activities  of  the 
process. 

L2-Process-138 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L2-Process-140 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L2-Process-142 

Reviews  and 

Audits 

List  of  reviews  and  audits. 

L2-Process-147 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L2-Process-149 

Measurements 

Description  of  process  measurements. 

L2-Process-150 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L2-Process-151 

Training 

List  of  training. 

L2-?roces.'-152 

Tools 

List  of  tools. 

2-Process- 153 
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SQA  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

The  SQA  plan  is  reviewed  by  the  affected 
groups  and  individuals.  (L2-63,  Al,  2) 

Affected 

individuals 

The  SQA  plan  is  reviewed  by  the  affected 
groups  and  individuals.  (L2-63,  Al,  2) 

Customer 

The  deliverable  software  products  are 
evaluated  before  they  are  delivered  to  the 
customer.  (L2-66,  A5,  1) 

Customer’s 

SQA 

personnel 

The  SQA  group  conducts  periodic  reviews 
of  its  activities  and  findings  with  the 
customer's  SQA  personnel,  as  appropriate. 
(L2-67,  A8) 

Experts 
independent  of 
the  SQA 
group 

Experts  independent  of  the  SQA  group 

periodically  review  the  activities  and 
software  work  products  of  the  project’s 

SQA  group.  (L2-69,  V3) 

Manager 

□  A  manager  is  assigned  specific 
responsibilities  for  the  project's  SQA 
activities.  (L2-62,  Ab2,  1 ) 

□  All  managers  in  the  SQA  reporting 
chain  to  the  senior  manager  are 
knowledgeable  in  the  SQA  role, 
responsibilities,  and  authority.  (L2-62, 
Ab2,  2.1) 

Continued  on  next  page 
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SQA  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Project 

manager 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  are 
documented  and  resolved  with  the 
appropriate  software  task  leaders, 
software  managers,  or  project 
manager,  where  possible.  (L2-67,  A7, 

1) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 

□  The  SQA  activities  are  reviewed  with 
the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
69,  V2) 

Senior 

management 

□  Senior  management  periodically 
reviews  the  SQA  activities  and  results. 
(L2-61,C1,  3) 

□  The  SQA  activities  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L2-68,  VI) 

Continued  on  next  page 
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SQA  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Senior 

manager 

□  A  senior  manager,  who  is 
knowledgeable  in  the  SQA  role  and  has 
the  authority  to  take  appropriate 
oversight  actions,  is  designated  to 
receive  and  act  on  software 
noncompliance  items.  (L2-62,  Ab2,  2) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 

□  Noncompliance  items  presented  to  the 
senior  manager  are  periodically 
reviewed  until  they  are  resolved.  (L2- 
67,  A7,  3) 

Software 

engineering 

group 

The  SQA  group  periodically  reports  the 
results  of  its  activities  to  the  software 
engineering  group.  (L2-67,  A6) 

Software 

manager 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  are 
documented  and  resolved  with  the 
appropriate  software  task  leaders, 
software  managers,  or  project 
manager,  where  possible.  (L2-67,  A7, 

1) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 

Continued  on  next  page 
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SQA  Process  -  Roies,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software  task 
leader 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  are 
documented  and  resolved  with  the 
appropriate  software  task  leaders, 
software  managers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 

SQA  group 

□  Members  of  the  SQA  group  are 
trained  to  perform  their  SQA  activities. 
(L2-62,  Ab3) 

□  The  SQA  group’s  activities  are 
performed  in  accordance  with  the  SQA 
plan.  (L2-64,  A2) 

□  The  SQA  group  participates  in  the 
preparation  and  review  of  the  project's 
software  development  plan,  standards, 
and  procedures.  (L2-65,  A3) 

Role  continues  on  next  page 

Continued  on  next  page 
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SQA  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page 


Role 

Activities  Participated  in... 

Reference 

SQA  group, 
continued 

□  The  SQA  group  provides  consultation 
and  review  of  the  plans,  standards,  and 
procedures  with  regard  to:  (L2-66,  A3, 
1) 

□  compliance  to  organizational 
policy, 

□  compliance  to  externally  imposed 
standards  and  requirements  (e.g., 
standards  imposed  by  the  statement 
of  work), 

□  standards  that  are  appropriate  for 
use  by  the  project, 

□  topics  that  should  be  addressed  in 
the  software  development  plan,  and 

□  other  areas  assigned  by  the  project. 

□  The  SQA  group  verifies  that  plans, 
standards,  and  procedures  are  in  place 
and  can  be  used  to  review  and  audit  the 
software  project.  (L2-66,  A3,  2) 

□  The  SQA  group  reviews  the  software 
engineering  activities  to  verify 
compliance.  (L2-66,  A4) 

□  The  SQA  group  audits  designated 
software  .vork  products  to  verify 
compliance.  (L2-66,  A5) 

□  The  SQA  group  periodically  reports 
the  results  o*"  its  activities  to  the 
software  engineering  group.  (L2-67, 
A6) 

□  The  SQA  group  conducts  periodic 
reviews  of  its  activities  and  findings 
with  the  customer's  SQA  personnel,  as 
appropriate.  (L2-67,  A8) 
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SQA  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


Genera]  entry 
criteria 


There  are  no  input-based  entry  criteria  in  the  software  quality  assurance  process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  quality  assurance  process. 


V 

Condition 

References 

The  project  follows  a  written  organizational  policy  for 
implementing  software  quality  assurance  (SQA).  (L2-60, 

Cl) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  SQA  policy.] 

A  group  that  is  responsible  for  coordinating  and 
implementing  SQA  for  the  project  (i.e.,  the  SQA  group) 
exists.  (L2-61,  Abl) 

1 

Adequate  resources  and  funding  are  provided  for 
performing  the  SQA  activities.  (L2-62,  Ab2) 

A  manager  is  assigned  specific  responsibilities  for  the 
project's  SQA  activities.  (L2-62,  Ab2,  1) 

A  senior  manager,  who  is  knowledgeable  in  the  SQA  role 
and  has  the  authority  to  take  appropriate  oversight  actions,  is 
designated  to  receive  and  act  on  software  noncompliance 
items.  (L2-62,  Ab2,  2) 

All  managers  in  the  SQA  reporting  chain  to  the  senior 
manager  are  knowledgeable  in  the  SQA  role, 
responsibilities,  and  authority.  (L2-62,  Ab2,  2.1) 

Tools  to  support  the  SQA  activities  are  made  available.  (,L2- 
62,  Ab2,  3) 

Members  of  the  SQA  group  are  trained  to  perform  their 

SQA  activities.  (L2-62,  Ab3) 

The  members  of  the  software  project  receive  orientation  on 
the  role,  responsibilities,  authority,  and  value  of  the  SQA 
group.  (L2-63,  Ab4) 
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SQA  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  quality  assurance 
process. 


V 

Input 

Org.  Input 

References 

Deliverable  software  products.  (L2-66,  A5, 
1) 

Designated  contractual  requirements.  (L2- 
66,  A5,  2) 

Designated  procedures.  (L2-66,  A4,  1) 

Designated  software  standards.  (L2-66, 

A4,  1) 

Designated  software  work  products.  (L2- 
66,  A5) 

Externally  imposed  requirements.  (L2-66, 
A3,  1.2) 

Externally  imposed  standards.  (L2-66,  A3, 
1.2) 

Project's  procedures.  (L2-65,  A3) 

Project's  software  development  plan.  (L2- 
65,  A3) 

Project's  standards.  (L2-65,  A3) 

Software  work  products.  (L2-66,  A5,  2) 

SQA  plan.  (L2-64,  A2) 
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SQA  Process  -  Activities 


Acitivities 


The  table  below  lists  the  recommended  activities  for  the  sotiware  quality  assurance 
process. 


V  }  Activities 

I  '  "  ■  — 

References 

A  SQA  plan  is  prepared  fo*"  the  software  project  according 
to  a  documented  procedure.  (L2-63.  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  SQA  group  participates  in  the  preparation  and  review 
of  the  project's  software  development  plan,  standards,  and 
procedures.  (L2-65,  A3) 

□  The  SQA  group  provides  consultation  and  review  of  the 
plans,  standards,  and  procedures  with  regard  to: 

□  compliance  to  organizational  policy, 

□  compliance  to  externally  imposed  standards  and 
requirements  (e.g.,  standards  required  by  the 
statement  of  work), 

□  standards  that  are  appropriate  for  use  by  the  project, 

□  topics  that  should  be  addressed  in  the  software 
development  plan,  and 

□  other  areas  as  assigned  by  the  project. 

□  The  SQA  group  verifies  that  plans,  standards,  and 
procedures  are  in  place  and  can  be  used  to  review  and 
audit  the  software  project. 

The  SQA  group  reviews  the  software  engineering  activities 

to  verify  compliance.  (L2-66,  A4) 

□  The  activities  are  evaluated  against  the  software 
development  plan  and  the  designated  software  standards 
and  procedures. 

□  Deviations  are  identified,  documented,  and  tracked  to 
closure. 

□  Corrections  are  verified. 

The  SQA  group  audits  designated  software  work  products 

to  verify  compliance.  (L2-66,  A5) 

□  The  deliverable  software  products  are  evaluated  before 
they  are  delivered  to  the  customer. 

□  The  software  work  products  are  evaluate^',  against  the 
designated  software  standards,  procedures,  and 
contractual  requirements. 

□  Deviations  are  identified,  documented,  and  tracked  to 
closure. 

□  Corrections  are  verified. 

Continued  on  next  page 
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3QA  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  quality  assurance 
process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  SQA  group  periodically  reports  the  results  of  its 
activities  to  the  software  engineering  group.  (L2-67,  A6) 

Deviations  identified  in  the  software  activities  and  software 
work  products  are  documented  and  handled  according  to  a 
documented  procedure.  (L2-67,  hi) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  SQA  group  conducts  periodic  reviews  of  its  activities 
and  findings  with  the  customer's  SQA  personnel,  as 
appropriate.  {L2-67,  A8) 

Measurements  are  made  and  used  to  determine  the  cost  and 
schedule  status  of  the  SQA  activities.  (L2-68,  Ml) 

The  SQA  activities  are  reviewed  with  senior  management  on 
a  periodic  basis.  (L2-68,  VI) 

The  SQA  activities  are  reviewed  with  the  project  manager 
on  a  periodic  and  event-driven  basis.  (L2-60,  V2) 

Experts  independent  of  the  SQA  group  periodically  review 
the  activities  and  software  work  products  of  the  project's 

SQA  group.  (L2-69,  V3) 
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SQA  Process  -  Outputs 


Outputs 


The  table  below  lists  the  outputs  produced  by  the  software  quality  assurance 
process. 


< 

Output 

Org.  Output 

References 

{  Corrections  to  deviations  between  the 
contractual  requirements  and  the 
j  designated  software  work  products.  (L2- 
1  67,  A5,  4) 

Corrections  to  deviations  between  the 
designated  software  procedures  and  the 
designated  software  work  products.  (L2- 
67,  A5,  4) 

Corrections  to  deviations  between  the 
designated  software  procedures  and  the 
software  engineering  activities.  (L2-66, 

A4.  3) 

Corrections  to  deviations  between  the 
designated  software  standards  and  the 
designated  software  work  products.  (L2- 
67,  A5,  4) 

Corrections  to  deviations  between  the 
designated  software  standards  and  the 
software  engineering  a^'-tivilies.  (L2-66, 

A4,  3) 

Corrections  to  deviations  between  the 
software  development  plan  and  the 
software  engineering  activities.  (L2-66, 

A4,  3) 

Deviations  between  the  contractual 
requirements  and  the  designated  software 
work  products.  (L2-67,  A5,  3) 

Deviations  between  the  designated  software 
procedures  and  the  designated  software 
work  products.  (L2-67,  A5,  3) 

Deviations  between  the  designated  software 
procedures  and  the  software  engineering 
activities.  (L2-66  A4,  2) 

Deviations  between  the  designated  software 
standards  and  the  designated  software  work 
products.  (L2-67,  A5,  3) 

J 

Deviations  between  the  designated  software 
standards  and  the  software  engineering 
activities.  (L2-66  A4,  2) 

Continued  on  next  page 
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SQA  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  software  quality  assurance 
process,  continued  from  the  previous  page. 


V 

Output 

Org.  Output 

References 

Deviations  between  the  software 
development  plan  and  the  software 
engineering  activities.  (L2-66  A4,  2) 

Deviations  from  the  designated  project 
procedures.  (L2-67,  A7,  1) 

Deviations  from  the  designated  project 
standards.  (L2-67,  A7,  1) 

Deviations  from  the  software  development 
plan.  (L2-67,  A7,  1) 

Deviations  identified  in  the  software 
activities.  (L2-67,  A7) 

Deviations  identified  in  the  software  work 
products.  (L2-67,  A7) 

Documentation  of  noncompliance  items. 
(L2-67,  A7.  4) 

Measurements  (to  determine  the  cost  and 
schedule  status  of  the  SQA  activities).  (L2- 
68,  Ml) 

Results  of  SQA  group  activities.  (L2-67, 
A6) 

Software  noncompliance  items.  (L2-62, 
Ab2,  2) 

Software  work  products  of  the  SQA 
group.  (L2-69,  V3) 

SQA  findings.  (L2-67,  A8) 

SQA  plan.  (L2-63,  Al) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  a  SQA  plan.] 

SQA  results.  (L2-61,C1,3) 
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SQA  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  assurance  process. 


V 

Output 

State 

References 

Corrections  to 
deviations  between 
the  contractual 
requirements  and  the 
designated  software 
work  products 

are  identified.  (L2-67,  A5,  4) 

Corrections  to 
deviations  between 
the  designated 
software  procedures 
and  the  designated 
software  work 
products 

are  identified.  (L2-67,  A5,  4) 

Corrections  to 
deviations  between 
the  designated 
software  procedures 
and  the  software 
engineering  activities 

are  identified.  (L2-66,  A4,  3) 

Corrections  to 
deviations  between 
the  designated 
software  standards 
and  the  designated 
software  work 
products 

are  identified.  (L2-67,  A5,  4) 

Corrections  to 
deviations  between 
the  designated 
software  standards 
and  the  software 
engineering  activities 

are  identified.  (L2-66,  A4,  3) 

Corrections  to 
deviations  between 
the  software 
development  plan 
and  the  software 
engineering  activities 

are  identified.  fL2-66,  A4,  3) 

Deviations  between 
the  contractual 
requirements  and  the 
designated  software 
work  products 

□  are  identified.  (L2-67,  A5,  3) 

□  are  documented.  (L2-67,  A5  3) 

□  are  tracked  to  closure.  (L2-6'i, 

A5,  3) 

■ 

i 

Continued  on  next  page 
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SQA  Process  -  Exit  Criteria,  Continued 


Output-ba^ed 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  assuiance  process,  continued  from  the  previous  page. 


Output 

State 

References 

Deviations  between 
the  designated 
software  procedures 
and  the  designated 
software  work 
products 

□  are  identified.  (L2-67,  A5,  3) 

□  are  documented.  (L2-67,  A5,  3) 

□  are  tracked  to  closure.  (L2-67, 
A5.  3) 

Deviations  between 
the  designated 
software  procedures 
and  the  software 
engineering  activities 

□  are  identified.  (L2-66,  A4,  2) 

□  are  documented.  (L2-66,  A4,  2) 

□  are  tracked  to  closure.  (L2-66, 
A4,  2) 

Deviations  between 
the  designated 
software  standards 
and  the  designated 
software  work 
products 

□  are  identified.  (L2-67,  A5,  3) 

□  are  documented.  (L2-67,  A5,  3) 

□  are  tracked  to  closure.  (L2-67, 
A5,  3) 

Deviations  between 
the  designated 
software  standards 
and  the  software 
engineering  activities 

Q  are  identified.  (L2-66,  A4,  2) 

□  are  documented.  (L2-66,  A4,  2) 

□  are  tracked  to  closure.  (L2-66, 
A4.  2) 

Deviations  between 
the  software 
development  plan 
and  the  software 
engineering  activities 

□  are  identified.  (L2-66,  A4,  2) 

□  are  documented.  (L2-66,  A4,  2) 

□  are  tracked  to  closure.  (L2-66, 
A4.2) 

1 

Deviations  from  the 
designated  project 
procedures 

□  are  documented.  (L2-67,  A7.  1 ) 

□  are  resolved  with  the  appropriate 
software  task  leaders,  '.oftware 
managers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1 ) 

□  not  resolvable  with  the  software 
task  leaders,  software  managers, 
or  project  manager  are 
documented  and  presented  to  the 
senior  manager  designated  to 
receive  noncompliance  items. 
(L2-67,  A7.  2) 

Continued  on  next  page 
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SQA  Process  -  Exit  Criteria,  Continued 


Output-b.'ised 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  assurance  process,  continued  from  the  previous  page. 


Output 

State 

References 

Deviations  from  the 
designated  project 
standards 

□  are  documented.  (L2-67.  A7,  1) 

□  are  resolved  with  the  appropriate 
software  task  leaders,  software 
managers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1) 

□  not  resolvable  with  the  software 
(ask  leaders,  software  managers, 
or  project  manager  are 

do  ~“*nted  and  presented  to  the 
;en;oi'  manager  designated  to 
.•eive  noncompliance  items. 
;i..:-67,  A7,  2) 

Deviations  from  the 
software  develo,*--"ent 
olan 

□  are  documented.  (L2-67,  A7,  1) 

□  are  resolved  with  the  appropriate 
software  task  leaders,  software 
managers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1) 

□  not  resolvable  with  the  software 
task  eaders,  software  managers, 

),roject  manager  are 
documented  and  presented  to  the 
senior  manager  designated  to 
receive  noncompliance  items. 
(L2-67,  A7,  2) 

Deviations  identified 
in  the  software 
activities 

□  are  documented.  (L2-67,  A7) 

□  are  handled  according  to  a 
documePisd  procedure.  (L2-67, 
A7) 

Deviations  identified 
in  the  softv  work 

products 

□  are  documented.  (L2-67,  A7) 

□  are  handled  according  to  a 
documented  procedure.  (L2-67, 
A7) 

Measurements  (to 
determine  the  cost 
and  schedule  status 
of  the  SQA  activities) 

□  are  made.  (L2  58,  Ml) 

□  are  used.  (L2-68,  Ml) 

Continued  on  next  page 
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SQA  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  assurance  process,  continued  from  the  previous  page. 


Output 

State 

References 

Noncompliance  items 
(presented  to  the 
senior  manager) 

□  are  periodically  reviewed  until 
they  are  resolved.  (L2-67.  A7,  3) 

□  are  documented.  (L2-67,  A7,  4) 

□  documentation  is  managed  and 
controlled.  (L2-67,  A7,  4) 

Results  of  SQA 
group  activities 

are  periodically  reported  to  the 
software  engineering  group.  (L2- 
67.  A6) 

SQA  plan 

□  is  prepared  for  the  software 
project  according  to  a 
documented  procedure.  (L2-63, 
Al) 

□  is  developed  in  the  early  stages 
of,  and  in  parallel  with,  the 
overall  project  planning.  (L2-63, 
Al,  1) 

□  is  reviewed  by  the  affected 
groups  and  individuals.  (L2-63, 
A1.2) 

□  is  managed  and  controlled.  (L2- 
64,  Al,  3) 

SQA  results 

are  reviewed  periodically  by  senior 
management.  (L2-61,C1,3) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  quality  assurance  process. 


Condition 

References 

The  SQA  group's  activities  are  performed  in  accordance 
with  the  SQA  plan.  (L2-64,  A2) 
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SQA  Process  >  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  quality  assurance  process,  continued  from  the  previous  page. 


Condition 

References 

The  SQA  group  participates  in  the  preparation  and  review 
of  the  project's  software  development  plan,  .standards,  and 
procedures.  (L2-65,  A3) 

□  The  SQA  group  provides  consultation  and  review  of  the 
plans,  standards,  and  procedures  with  regard  to; 

□  compliance  to  organizational  policy, 

□  compliance  to  externally  imposed  standards  and 
requirements  (e.g.,  standards  required  by  the 
statement  of  work), 

□  standards  that  are  appropriate  for  use  by  the  project, 

□  topics  that  should  be  addressed  in  the  software 
development  plan,  and 

□  other  areas  as  assigned  by  the  project. 

□  The  SQA  group  verifies  that  plans,  standards,  and 
procedures  are  in  place  and  can  be  used  to  review  and 
audit  the  software  project. 

The  SQA  group  reviews  the  software  engineering  activities 
to  verify  compliance.  (L2-66,  A4) 

The  software  engineering  activities  are  evaluated  against  the 
software  development  plan  and  the  designated  software 
standards  and  procedures.  (L2-66,  A4,  1) 

The  SQA  group  audits  designated  software  work  products 
to  verify  complia.ice.  (L2-66,  A5) 

□  The  deliverable  software  products  are  evaluated  before 
they  are  delivered  to  the  customer. 

□  The  software  work  products  are  evaluated  against  the 
designated  software  standards,  procedures,  and 
contractual  requirements. 

The  SQA  group  conducts  periodic  reviews  of  its  activities 
and  findings  with  the  customer's  SQA  personnel,  as 
appropriate.  (L2-67,  A8) 

The  SQA  activities  are  reviewed  with  senior  management  on 
a  periodic  basis.  (L2-68,  VI) 

The  SQA  activities  are  reviewed  with  the  project  manager 
on  a  periodic  and  event-driven  basis.  (L2-69,  V2) 

Experto  independent  of  the  SQA  group  periodically  review 
the  activities  and  software  work  products  of  the  project’s 

SQA  group.  (L2-69,  V3) 
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SQA  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  quality 
assurance  process. 


Review  or  Audit 

Review 

Participants 

References 

Senior  management  periodically  reviews 
the  SQA  activities  and  results.  (L2-61,  Cl, 
3) 

Senior 

management 

The  SQA  plan  is  reviewed  by  the  affected 
groups  and  individuals.  (L2-63,  Al,  2) 

Affected 

groups 

Affected 

individuals 

The  SQA  group  participates  in  the 
preparation  and  review  of  the  project's 
software  development  plan,  standards,  and 
procedures.  (L2-65,  A3) 

SQA  group 

The  SQA  group  provides  consultation  and 

review  of  the  plans,  standards,  and 

procedures  with  regard  to;  (L2-66,  A3,  I) 

□  compliance  to  organizational  policy, 

□  compliance  to  externally  imposed 
standards  and  requirements  (e.g., 
standards  required  by  the  statement  of 
work), 

□  standards  that  are  appropriate  for  use 
by  the  project, 

□  topics  that  should  be  addressed  in  the 
software  development  plan,  and 

□  other  areas  as  assigned  by  the  project. 

SQA  group 

The  SQA  group  reviews  the  software 
engineering  activities  to  verify  compliance. 
(L2-66,  A4) 

SQA  group 

The  SQA  group  audits  designated  software 
work  products  to  verify  compliance.  (L2- 
66,  A5) 

SQA  group 

The  SQA  group  conducts  periodic  reviews 
of  its  activities  and  findings  with  the 
customer's  SQA  personnel,  as  appropriate. 
(L2-67,  A8) 

SQA  group 

Customer's 

SQA 

personnel 

The  SQA  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  fL2-68, 
VI) 

Senior 

management 
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SQA  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  quality 
assurance  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  SQA  activities  are  reviewed  with  the 
project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-69,  V2) 

Project 

manager 

Experts  independent  of  the  SQA  group 
periodically  review  the  activities  and 
software  work  products  of  the  project’s 

SQA  group.  (L2-69,  V3) 

Experts 
independent  of 
the  SQA 
group 

SQA  group 
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Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  mai  aged  and 
controlled  during  the  software  quality  assurance  process. 


R" 

W'ork  Products  Managed  and  Controlled 

References 

SQA  plan.  (L2-64.  Al,  3) 

Documentation  of  noncompliance  items.  (L2-67,  A7,  4) 
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Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software  quality 
assurance  process. 


V 

Measurements 

References 

Measurements  are  made  and  used  to  determine  the  cost  and 

schedule  status  of  SQA  activities.  (L2-68,  Ml) 

Examples  of  measurements  include: 

□  Completions  of  mi.lestones  for  the  SQA  activities 
compared  to  the  plan. 

□  Work  completed,  effort  expended,  and  funds  expended 
in  the  SQA  activities  compared  to  the  plan. 

□  Numbers  of  product  audits  and  activity  reviews 
compared  to  the  plan. 
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SQA  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  software  quality  assurance  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


Documented  procedures 

References 

A  SQA  plan  is  prepared  for  the  software  project  according 
to  a  documented  procedure.  (L2-63,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Deviations  identified  in  the  software  activities  and  software 
work  products  are  documented  and  handled  according  to  a 
documented  procedure.  (L2-67,  A7) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 
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SQA  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  quality  assurance 
process. 


V 

Training 

References 

Members  of  the  SQA  group  are  trained  to  perform  their 
SQA  activities.  (L2-62,  Ab3) 

The  members  of  the  software  project  receive  orientation  on 
the  role,  responsibilities,  authority,  and  value  of  the  .'JQA 
group.  (L2-63,  Ab4) 
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SQA  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  software  quality  assurance 
process. 


a/ 

Tools 

References 

_ 

Tools  to  support  the  SQA  activities.  (L2-62,  Ab2,  3) 
Examples  of  support  tools  include: 

□  workstations, 

□  database  programs, 

□  spreadsheet  programs,  and 

□  auditing  tools. 
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Software  Configuration  Management  (SCM)  Process 
SCM  Process  -  Overview 


SCM  process 
purpose 


SCM  process 
description 


The  purpose  of  Software  Configuration  Management  is  to  establish  and  maintain 
the  integrity  of  the  products  of  the  software  project  throughout  the  project's 
software  life  cycle.  (L2-71) 


Software  Configuration  Management  involves  identifying  the  configuration  of  the 
software  (i.e.,  selected  software  work  products  and  their  descriptions)  at  given 
points  in  time,  systematically  controlling  changes  to  the  configuration,  and 
maintaining  the  integrity  and  traceability  of  the  configuration  throughout  the 
software  life  cycle.  The  work  products  placed  under  software  configuration 
management  include  the  software  products  that  are  delivered  to  the  customer  (e.g., 
the  software  requirements  document  and  the  code)  and  the  items  that  are  identified 
with  or  required  to  create  these  software  products  (e.g.,  the  compiler). 

A  software  baseline  library  is  established  containing  the  software  baselines  as  they 
are  developed.  Changes  to  baselines  and  the  release  of  software  products  built 
from  the  software  baseline  library  are  systematically  controlled  via  the  change 
control  and  configuration  auditing  functions  of  software  configuration 
management. 

This  key  process  area  covers  the  practices  for  performing  the  software 
configuration  management  function.  T>-.  practices  identifying  specific 
configuration  items/units  are  contained  in  the  key  process  areas  that  describe  the 
development  and  maintenance  of  each  configuration  item/unit.  (L2-71) 


Continued  on  next  page 
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SCM  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L2-Process-I57 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L2-Process-161 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L2-Process-162 

Activities 

Description  of  the  activities  of  the 
process. 

L2-Process-163 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L2- Process- 1 65 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L2-Process-166 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L2-Process-172 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L2-Process-174 

Measurements 

Description  of  process  measurements. 

L2-Process-175 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L2-Process-176 

Training 

List  of  training. 

L2-Process-177 

Tools 

List  of  tools. 

L2-Process-178 
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SCM  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process. 


Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

□  The  SCM  plan  is  reviewed  by  the 
affected  groups. 

□  The  configuration  management  library 
system  provides  for  the  sharing  and 
transfer  of  configuration  items/units 
between  the  affected  groups  and 
between  control  levels  within  the 
library.  (L2-78,  A3,  3) 

□  Standard  reports  documenting  the  SCM 
activities  and  the  contents  of  the 
software  baseline  are  developed  and 
made  available  to  affected  groups  and 
individuals.  (L2-81,  A9) 

Affected 

individuals 

Standard  reports  documenting  the  SCM 
activities  and  the  contents  of  the  software 
baseline  are  developed  and  made  available 
to  affected  groups  and  individuals.  (L2- 
81.  A9) 

Manager 

A  manager  is  assigned  specific 
responsibilities  for  SCM.  (L2-75,  Ab3,  1 ) 

Person 

responsible  for 
each 

configuration 
uni  t/i  tern 

The  person  responsible  for  each 
configuration  item/unit  (i.e.,  the  owner, 
from  a  configuration  management  point  of 
view)  is  identified.  (L2-79,  A4,  6) 

Project 

manager 

The  SCM  activities  are  reviewed  with  the 
project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-83,  V2) 

Project 

software 

manager 

The  results  of  software  baseline  audits  are 
reported  to  the  project  software  manager. 
(L2-82,  A 10,  6) 

Senior 

management 

The  SCM  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2-82, 

vn 

! 

Continued  on  next  page 
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SCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software 
configuration 
control  board 
(SCCB) 

□  A  board  having  the  authority  for 
managing  the  project’s  software 
baselines  (i.e.,  a  software  conflguration 
control  board  -  SCCB)  exists  or  is 
established.  (L2-73,  Abl) 

The  SCCB; 

□  Authorizes  the  establishment  of 
software  baselines  and  the 
identification  of  configuration 
items/units. 

□  Represents  the  interests  of  the 
project  manager  and  all  groups 
who  may  be  affected  by  changes  to 
the  software  baselines. 

□  Reviews  and  authorizes  changes  to 
the  software  baselines. 

□  Authorizes  the  creation  of  products 
from  the  software  baseline  library. 

□  Only  configuration  items/units  that  are 
approved  by  the  SCCB  are  entered  into 
the  software  baseline  library.  (L2-80, 
A6,  2) 
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SCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process,  continued  from  the  previous  page. 


v 

Role 

Activities  Participated  in... 

Reference 

Software 
configuration 
management 
(SCM)  group 

□  A  group  that  is  responsible  for 
coordinating  and  implementing  SCM 
for  the  project  (i.e.,  the  SCM  group) 
exists.  (L2-74,  Ab2) 

The  SCM  group  coordinates  or 
implements: 

□  Creation  and  management  of  the 
project's  software  baseline  library. 

□  Development,  maintenance,  and 
distribution  of  the  SCM  pl.ans, 
standards,  and  procedures. 

□  The  identification  of  the  set  of 
work  products  to  be  placed  under 
SCM. 

□  Management  of  the  access  to  the 
software  baseline  library. 

□  Updates  of  the  software  baselines. 

□  Creation  of  products  from  the 
software  baseline  library. 

□  Recording  of  SCM  actions. 

□  Production  and  distribution  of 

SCM  reports. 

□  Members  of  the  SCM  group  are 
trained  in  the  objectives,  procedures, 
and  methods  for  performing  their  SCM 
activities.  {L2-76,  Ab4) 

□  The  SCM  group  periodically  audits 
:-.offware  baselines  to  verify  that  they 
conform  to  the  documentation  that 
defines  them.  (L2-83,  V3) 

Software 

engineering 

group 

Members  of  the  software  engineering 
group  and  other  software-related  groups 
are  trained  to  perform  their  SCM  activities. 
(L2-76,  Ab5) 
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SCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software- 
related  groups 

□  Members  of  the  software  engineering 
group  and  other  software-related 
groups  are  trained  to  perform  their 

SCM  activities.  (L2-76,  Ab5) 

□  The  SCM  plan  covers  the  SCM 
requirements  and  activities  to  be 
performed  by  the  software  engineering 
group  and  other  software-related 
groups.  (L2-77,  A2,  2) 

SQA  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  SCM  and  reports  the  results. 
(L2-83.  V4) 
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SCM  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  software  configuration  management  process. 


V 

Input 

State 

References 

Change  requests  for 

configuration 

items/units 

are  initiated  according  to  a 
documented  procedure.  (L2-79,  A5) 

Problem  reports  for 

configuration 

items/units 

are  initiated  according  to  a 
documented  procedure.  (L2-79,  A5) 

SCM  plan 

□  !•:  documented.  (L2-77,  A2) 

□  is  approved.  (L2-77,  A2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  configuration  management  process. 


V 

Condition 

References 

The  project  follows  a  written  organizational  policy  for 
implementing  software  configuration  management  (SCM). 
(L2-72.  Cl) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  SCM  policy.] 

Responsibility  for  SCM  for  each  project  is  explicitly 
assigned.  (L2-72,  Cl,l) 

A  board  having  the  authority  for  managing  the  project's 
software  baselines  (i.e.,  a  software  configuration  control 
board  -  SCCB)  exists  or  is  established.  (L2-73,  Abl) 

A  group  that  is  responsible  for  coordinating  and 
implementing  SCM  for  the  project  (i.e.,  the  SCM  group) 
exists.  (L2-74,  Ab2) 

Adequate  resources  and  funding  are  provided  for 
performing  the  SCM  activities.  (L2-75,  Ab3) 

A  manager  is  assigned  specific  responsibilities  for  SCM. 
(L2-75,  Ab3,  I) 

Tools  to  support  the  SCM  activities  are  made  available.  (L2- 
75,  Ab3,  2) 

Members  of  the  SCM  group  are  trained  in  the  objectives, 
procedures,  and  methods  for  performing  their  SCM 
activities.  (L2-76,  Ab4) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  are  trained  to  perform  their  SCM 
activities.  (L2-76,  Ab5) 
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SCM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  configuration 
management  process. 


Input 

Org.  Input 

References 

Change  requests  for  configuration 
items/units.  (L2-79,  A5) 

Changes  to  baselines.  (L2-80,  A6) 

Configuration  items/units.  (L2-78,  A3,  2) 

Designated  internal  software  work 
products.  (L2-72,  Cl,3) 

Designated  support  tools  used  inside  the 
project.  (L2-72,  Cl,  3) 

Externally  deliverable  software  products. 
(L2-72,  Cl,  3) 

Problem  reports  for  configuration 
items/units.  (L2-79,  A5) 

SCM  plan.  (L2-77,  A2) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  a  SCM  plan.] 

Software  baselines.  (L2-73,  Cl,5) 

Software  work  products.  (L2-78,  A4) 

Updates  of  the  software  baselines.  (L2-75, 
Ab2,  5) 

Work  products  to  be  placed  under  SCM. 
(L2-75,  Ab2,  3) 
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SCM  Process  -  Activities 


Act!  /ities 


The  table  below  lists  the  recommended  activities  for  the  software  configuration 
management  process. 


V 

Activities 

References 

A  SCM  plan  is  prepared  for  each  software  project  according 
to  a  documented  procedure.  (L2-76,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

A  documented  and  approved  SCM  plan  is  used  as  the  basis 
for  performing  the  SCM  activities.  (L2-77,  A2) 

A  configuration  management  library  system  is  established  as 
a  repository  for  the  software  baselines.  (L2-77,  A3) 

[Refer  to  SCM  Process  Tools  for  additional  information 
regarding  a  configuration  management  library  system.] 

The  software  work  products  to  be  placed  under 

configuration  management  are  identified.  (L2-78,  A4) 

□  The  configuration  items/units  are  selected  based  on 
documented  criteria. 

□  The  configuration  items/units  are  assigned  unique 
identifiers. 

□  The  characteristics  of  each  configuration  item/unit  are 
specified. 

□  The  software  baselines  to  which  each  configuration 
item/unit  belongs  are  specified. 

□  The  point  in  its  development  that  each  configuration 
item/unit  is  placed  under  configuration  management  is 
specified. 

□  The  person  responsible  for  each  configuration  item/unit 
(i.e.,  the  owner,  from  a  configuration  management  point 
of  view)  is  identified. 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

Changes  to  baselines  are  controlled  according  to  a 
documented  procedure.  (L2-80,  A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 
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SCM  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  configuration 
management  process,  continued  from  the  previous  page. 


Activities 

References 

Products  from  the  software  baseline  library  are  created  and 
their  release  is  controlled  according  to  a  documented 
procedure.  (L2-80,  A7,) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  status  of  configuration  items/units  is  recorded  according 
to  a  documented  procedure.  (L2-80,  A8) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Standard  reports  documenting  the  SCM  activities  and  the 
contents  of  the  software  baseline  are  developed  and  made 
available  to  affected  groups  and  individuals.  (L2-81,  A9) 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Measurements  are  made  and  used  to  determine  the  status  of 
the  SCM  activities.  (L2-82,  Ml) 

The  SCM  activities  are  reviewed  with  senior  management  on 
a  periodic  basis.  (L2-82,  VI) 

The  SCM  activities  are  reviewed  with  the  project  manager 
on  both  a  periodic  and  event-driven  basis.  (L2-83,  V2) 

The  SCM  group  periodically  audits  software  baselines  to 
verify  that  they  conform  to  the  documentation  that  defines 
them.  (L2-83,  V3) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  SCM  and  reports  the 
results.  (L2-83,  V4) 

[Refer  to  SCM  Process  Reviews  and  Audits  for  additional 
information.] 
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SCM  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  software 
configuration  management  process. 


V 

Output 

Org.  Output 

References 

Action  items  from  the  software  baseline 
audit.  (L2-82,  AlO,  7) 

Archive  versions  of  configuration 
items/units.  (L2-78,  A3,  5) 

Changes  to  the  software  baselines.  (L2-74, 
Abl,  3) 

Configuration  items/units.  (L2-73,  Abl,  1) 

Current  status  and  history  (i.e.,  changes 
and  other  actions)  of  each  configuration 
item/unit.  (L2-81,A8,  2) 

Measurements  (to  determine  the  status  of 
the  SCM  activities).  (L2-82,  Ml) 

Products  from  the  software  baseline 
library.  (L2-74,  Abl,  4) 

Project's  software  baseline  library  (or 
repository).  (L2-75,  Ab2,  1) 

Results  of  the  software  baseline  audit.  (L2- 
82,  AlO,  6) 

Results  of  SQA  group  reviews  and/or 
audits  of  the  activities  and  work  products 
for  SCM.  (L2-83,  V4) 

SCM  plan.  (L2-75,  Ab2,  2) 

_ I 

SCM  procedures.  (L2-75,  Ab2,  2) 

SCM  records.  (L2-72,  Cl,  4) 

SCM  reports.  (L2-75,  Ab2,  8) 

SCM  standards.  (L2-75,  Ab2,  2) 

Software  baselines.  (L2-73,  Abl) 

Standard  reports  documenting  the  SCM 
activities  and  the  contents  of  the  software 
baseline.  (L2-81,  A9) 

Work  products  to  be  placed  under  SCM. 
(L2-75,  Ab2,  3) 
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SCM  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  management  process. 


Output 

State 

References 

Action  items  from 
the  software  baseline 
audit 

are  tracked  to  closure.  (L2-82,  A 10. 
7) 

Changes  to  the 
software  baselines 

□  are  reviewed  by  the  SCCB.  (L2- 
74,  Abl,  3) 

□  are  authorized  by  the  SCCB. 
(L2-74,  Abl.  3) 

□  are  controlled  according  to  a 
documented  procedure.  (L2-80, 
A6) 

Configuration 

items/units 

□  identification  is  authorized  by 
the  SCCB.  (L2-73,  Abl,  1) 

□  are  selected  based  on 
documented  criteria.  (L2-79, 

A4.  1) 

□  are  assigned  unique  identifiers. 
(L2-79,  A4,  2) 

□  characteristics  are  specified. 
(L2-79,  A4.  3) 

□  are  checked  in  and  out  in  a 
manner  that  maintains  the 
correctness  and  integrity  of  the 
software  baseline  library.  (L2- 
80.  A6,  3) 

□  current  status  and  history  (i.e., 
changes  and  other  actions)  are 
maintained.  (L2-81,  A8.  2) 

Configuration 
item’s/unit’s  history 
(i.e.,  changes  and 
other  actions) 

is  maintained.  (L2-81,  A8,  2) 

Configuration 
item’s/unit's  status 

□  is  recorded  according  to  a 
documented  procedure.  (L2-80, 
A8) 

□  is  maintained.  (L2-81,  A8,  2) 

Measurements  (to 
determine  the  status 
of  the  SCM  activities) 

□  are  made.  (L2-82,  Ml) 

□  are  used.  (L2-82,  Ml) 
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SCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


Output 

State 

References 

Products  from  the 
software  baseline 
library 

□  are  authorized  to  be  created  by 
theSCCB.  (L2-74,  Abl,  4) 

□  creation  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  6) 

□  are  created  and  their  release  is 
controlled  according  to  a 
documented  procedure.  (L2-80, 
A7) 

□  for  both  internal  and  external 
use,  are  built  only  from 
configuration  items/units  in  the 
software  baseline  library.  (L2- 
80,  A7,  2) 

Project's  software 
baseline  library  (or 
repository) 

□  is  established  or  is  accessible  to 
the  projects  for  storing 
configuration  items/units  and  the 
associated  SCM  records.  (L2-72, 
Cl,  4) 

□  creation  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-.’5,  Ab2,  1) 

□  management  is  coordinated  or 
implemented  by  the  SCM  group, 
(L2-75,  Ab2,  1) 

□  access  management  is 
coordinated  or  implemented  by 
the  SCM  group.  (L2-75,  Ab2, 

4) 

□  completeness  of  contents  is 
verified.  (L2-81,  A 10,  4) 

□  correctness  of  contents  is 
verified.  (L2-81,  AlO,  4) 

Results  of  the 
software  baseline 
audit 

are  reported  to  the  project  software 
manager.  (L2-82,  AlO,  6) 
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SCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

Results  of  SQA 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  SCM 

are  reported.  (L2-83,  V4) 

SCM  plan 

□  development  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  maintenance  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  is  prepared  for  each  software 
project  according  to  a 
documented  procedure.  (L2-76 
Al) 

□  is  developed  in  the  early  stages 
of,  and  in  parallel  with,  overall 
project  planning.  (L2-76,  Al,  1) 

□  is  reviewed  by  the  affected 
groups.  (L2-77,  Al,2) 

□  is  managed  and  controlled.  (L2- 
77,  Al,  3) 

□  is  documented.  (L2-77,  A2) 

□  is  approved.  (L2-77,  A2) 

□  is  used  as  the  basis  for 
performing  the  SCM  activities. 
(L2-77,  A2) 

SCM  procedures 

□  development  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
fL2-75,  Ab2,  2) 

□  maintenance  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 
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SCM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

SCM  reports 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  8) 

□  production  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  8) 

SCM  standards 

□  development  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  maintenance  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2.  2) 

Software  baselines 

□  are  authorized  to  be  established 
bytheSCCB.  (L2-73.  Abl,  1) 

□  updates  are  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75.  Ab2,  5) 

□  to  which  each  configuration 
item/unit  belongs  are  specified. 
(L2-79,  A4,  4) 

□  integrity  is  assessed.  (L2-81, 

AlO,  2) 

Standard  reports 
documenting  the 

SCM  activities 

□  are  developed.  (L2-81,  A9) 

□  are  made  available  to  affected 
groups  and  individuals.  (L2-81, 
A9) 

Standard  reports 
documenting  the 
contents  of  the 
software  baseline 

□  are  developed,  (L2-81,  A9) 

□  are  made  available  to  affected 
groups  and  individuals.  (L2-81, 
A9) 

L_ 

Work  products  to  be 
placed  under  SCM 

□  identification  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  3) 

□  are  identified.  (L2-78,  A4) 
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SCM  Process  -  Exit  Criteria,  Continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  configuration  management  process. 


V 

Condition 

References 

SCM  is  implemented  throughout  the  project’s  life  cycle. 
(L2-72,  Cl,  2) 

SCM  is  implemented  for  externally  deliverable  software 
products,  designated  internal  software  work  products,  and 
designated  support  tools  used  inside  the  project  (e.g., 
compilers).  (L272,  Cl,  3) 

The  SCM  group  coordinates  or  implements  the  recording  of 
SCM  actions.  (L2-75,  Ab2,  7) 

A  configuration  management  library  system  is  established  as 
a  repository  for  the  software  baselines.  (L2-77,  A3) 

The  point  in  its  development  that  each  configuration 
item/unit  is  placed  under  configuration  management  is 
specified.  (L2-79,  A4,  5) 

1 

The  person  responsible  for  each  configuration  item/unit  (i.e., 
the  owner,  from  a  configuration  management  point  of  view) 
is  identified.  (L2-79,  A4,  6) 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

Reviews  and/or  regression  tests  are  performed  to  ensure  that 
changes  have  not  caused  unintended  effects  on  the  baseline. 
(L2-80,  A6,  1) 

Only  configuration  items/units  that  are  approved  by  the 
SCCB  are  entered  into  the  software  baseline  library.  (L2-80, 
A6,  2) 

The  configuration  management  actions  are  recorded  in 
sufficient  detail  so  that  the  content  and  status  of  each 
configuration  item/unit  are  known  and  previous  versions  can 
be  recovered.  (L2-81,  A8,  1) 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10) 

The  SCM  activities  are  reviewed  with  senior  management  on 
a  periodic  basis.  (L2-82,  VI) 

The  SCM  activities  are  reviewed  with  the  project  manager 
on  both  a  periodic  and  event-driven  basis.  (L2-83,  V2) 
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SCM  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


V 

Condition 

References 

The  SCM  group  periodically  audits  software  baselines  to 
verify  that  they  conform  to  the  documentation  that  defines 
them.  (L2-83,  V3) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  SCM  and  reports  the 
results.  (L2-83,  V4) 
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SCM  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
configuration  management  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  software  baselines  ana  SCM  activities 
are  audited  on  a  periodic  basis.  (L2-73, 

Cl,  5) 

Not  specified  in 
CMM 

The  .SCCB  reviews  and  authorizes  changes 
to  the  software  basehnes.  (L2-74,  Abl,  3) 

SCCB 

The  SCM  plan  is  reviewed  by  the  affected 
groups.  (L2-77,  Al,  2) 

Affected 

groups 

Change  requests  and  problem  reports  for 
all  configuration  items/unlts  are  initiated, 
recorded,  reviewed,  approved,  and  tracked 
according  to  a  documented  procedure. 
(L2-79,  A5) 

Not  specified  in 
CMM 

Reviews  and/or  regression  tests  are 
performed  to  ensure  that  changes  have  not 
caused  unintended  effects  on  the  baseline. 
(L2-80.  A6,  I) 

Not  specified  in 
CMM 

Software  baseline  audits  are  conducted 
according  to  a  documented  procedure. 
(L2-81,  AlO) 

Not  specified  in 
CMM 

The  SCM  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2-82, 
VI) 

Senior 

management 

The  SCM  activities  are  reviewed  with  the 
project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-83,  V2) 

Project 

manager 

The  SCM  group  periodically  audits 
software  baselines  to  verify  that  they 
conform  to  the  documentation  that  defines 
them.  (L2-83,  V3) 

SCM  group 

Continued  on  next  page 
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SCM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
configuration  management  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  SCM  and  reports  the  results. 
(L2-83,  V4) 

At  a  minimum,  the  reviews  and/or  audits 
verify: 

□  Compliance  with  the  SCM  standards 
and  procedures  by: 

□  the  SCM  group, 

□  theSCCB, 

□  the  software  engineering  group, 
and 

□  other  software-related  groups. 

□  Occurrence,  of  periodic  baseline  audits. 

SQA  group 
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Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  managed  and 
controlled  during  the  configuration  management  process. 


Work  Products  Managed  and  Controlled 

References 

SCM  plan.  (L2-77,  Al,3) 
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SCM  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software 
configuration  management  process. 


Measurements 

References 

I 

Measurements  are  made  and  used  to  determine  the  status  of 
the  SCM  activities.  (L2-82,  Ml) 

Examples  of  measurements  include: 

□  Number  of  change  requests  processed  per  unit  time. 

□  Completions  of  milestones  for  the  SCM  activities 
compared  to  the  plan. 

□  Work  completed,  effort  expended,  and  funds  expended 
in  the  SCM  activities. 
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SCM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  software  configuration  management 
process  recommended  to  be  performed  according  to  a  documented  procedure. 


V 

Documented  procedures 

References 

A  SCM  plan  is  prepared  for  each  software  project  according 
to  a  documented  procedure.  (L2-76,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

( 

Changes  to  baselines  are  controlled  according  to  a 
documented  procedure.  (L2-80,  A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.) 

Products  from  the  software  baseline  library  are  created  and 
their  release  is  controlled  according  to  a  documented 
procedure.  (L2-80,  A7) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.) 

The  status  of  configuration  items/units  is  recorded  according 
to  a  documented  procedure.  (L2-80,  A8) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.) 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.) 
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SCM  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  configuration 
management  process. 


V 

Training 

References 

Members  of  the  SCM  group  are  trained  in  the  objectives, 
procedures,  and  methods  for  performing  their  SCM 
activities.  (L2-76,  Ab4) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  are  trained  to  perform  their  SCM 
activities.  (L2-76,  Ab5) 
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SCM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  software  configuration 
management  process. 


Tools 

References 

Tools  to  support  the  SCM  activities.  (L2-75,  Ab3,  2) 
Examples  of  support  tools  include: 

□  workstations, 

□  database  programs,  and 

□  configuration  management  tools. 

A  configuration  management  library  system  is  established  as 

a  repository  for  the  software  baselines.  (L2-77,  A3) 

This  library  system: 

□  Supports  multiple  control  levels  of  SCM. 

□  Provides  for  the  storage  and  retrieval  of  configuration 
items/units. 

□  Provides  for  the  sharing  and  transfer  of  configuration 
items/units  between  the  affected  groups  and  between 
control  levels  within  the  library. 

□  Helps  in  the  use  of  product  standards  for  configuration 
items/units. 

□  Provides  for  the  storage  and  recovery  of  archive  versions 
of  configuration  items/units 

□  Helps  to  ensure  correct  creation  of  prodr  ■'•s  from  the 
software  baseline  library. 

□  Provides  for  the  storage,  update,  and  retrieval  of  SCM 
records. 

□  Supports  production  of  SCM  reports. 

□  Provides  for  the  maintenance  of  the  library  structure  and 
contents. 
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Level  2  Procedure  Checklists 
Overview 


Introduction 


Purpose 


In  this  section 


This  section  describes  all  the  explicit  documented  procedures  recommended  in  the 
Capability  Maturity  Model  for  maturity  level  2. 


The  purpose  of  the  procedure  checklists  is  to  provide: 

•  Guidance  in  identifying  which  procedures  are  recommended  by  the  CMM  at 
level  2. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  procedures  to 
determine  if  those  procedures  are  consistent  with  the  CMM  at  level  2. 

•  Information  that  can  be  used  to  develop  software  procedures  that  are  consistent 
with  the  CMM  at  level  2. 


This  section  covers  the  following  documented  procedures: 


CMM  Level  2  Procedures 

See  Page 

Requirements  management  procedures 

L2-Procedures-2 

Software  project  planning  procedures 

L2-Procedures-3 

Software  project  tracking  &  oversight  procedures 

L2-Procedures-6 

Software  subcontract  management  procedures 

L2-Procedures-7 

Software  quality  assurance  procedures 

L2-Procedures-l  1 

Software  configuration  management  procedures 

L2-Procedures-12 
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Requirements  Management  (RM)  Procedures 


Documented 

procedures 


There  are  no  recommended  documented  procedures  for  the  requirements 
management  process. 
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Software 


Documented 

procedures 


Project  Planning  (SPP)  Procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
project  planning  process. 


~T 

Documented  Procedures 

References 

Software  project  commitments  made  to  individuals  and 
groups  external  to  the  organization  are  reviewed  with  senior 
management  according  to  a  documented  procedure.  (L2- 
17.  A4) 

The  project's  software  development  plan  is  developed 
according  to  a  documented  procedure.  (L2-18,  A6) 

This  procedure  typically  specifies  that: 

□  The  software  development  plan  is  based  on  and 
conforms  to: 

□  the  customer's  standards,  as  appropriate; 

□  the  project's  standards; 

□  the  approved  statement  of  work;  and 

□  the  allocated  requirements. 

□  Plans  for  software-related  groups  and  other 
engineering  groups  involv^  in  the  activities  of  the 
software  engineering  group  are  negotiated  with  those 
groups,  the  support  efforts  arc  budgeted,  and  the 
agreements  are  documented. 

□  Plans  for  involvement  of  the  software  engineering 
group  in  the  activities  of  other  software-related  groups 
and  other  engineering  groups  are  negotiated  with  those 
groups,  the  support  efforts  are  budgeted,  and  the 
agreements  are  documented. 

□  The  software  development  plan  is  reviewed  by: 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  The  software  development  plan  is  managed  and 
controlled. 

Continued  on  next  page 
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Software 


Documented 

procedures, 

continued 


Project  Planning  (SPP)  Procedures,  Continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
project  planning  process,  continued  from  the  previous  page. 


~T 

Documented  Procedures 

References 

Estimates  for  the  size  of  the  software  work  products  (or 
changes  to  the  size  of  software  work  products)  are  derived 
according  to  a  documented  procedure.  (L2-21,  A9) 

This  procedure  typically  specifies  that: 

□  Size  estimates  are  made  for  all  major  software  work 
products  and  activities. 

□  Software  work  products  are  decomposed  to  the 
granularity  needed  to  meet  the  estimating  objectives. 

□  Historical  data  are  used  where  available. 

□  Size  estimating  assumptions  are  documented. 

□  Size  estimates  are  documented,  reviewed,  and  agreed  to. 

Estimates  for  the  software  project's  effort  and  costs  are 
derived  according  to  a  documented  procedure.  (L2-22, 

AlO) 

This  procedure  typically  specifies  that: 

□  Estimates  for  the  software  project's  effort  and  costs  are 
related  to  the  size  estimates  of  the  software  work 
products  (or  the  size  of  the  changes). 

□  Productivity  data  (historical  and/or  current)  are  used  for 
the  estimates  when  available;  sources  and  rationale  for 
these  data  are  documented. 

□  The  productivity  and  cost  data  are  from  the 
organization's  projects  when  possible. 

□  The  productivity  and  cost  data  take  into  account  the 
effon  and  significant  costs  that  go  into  making  the 
software  work  products. 

□  Effort,  staffing,  and  cost  estimates  are  based  on  past 
experience. 

□  Similar  projects  should  be  used  when  possible. 

□  Time  phasing  of  activities  is  derived. 

□  Distributions  of  the  effort,  staffing,  and  cost 
estimates  over  the  software  life  cycle  are  prepared. 

□  Estimates  and  the  assumptions  made  in  deriving  the 
estimates  are  documented,  reviewed,  and  agreed  to. 

Continued  on  next  page 
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Software  Project  Planning  (SPP)  Procedures,  continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
project  planning  process,  continued  from  the  previous  page. 


T 

Documented  Procedures 

References 

Estimates  for  the  project’s  critical  computer  resources  are 
derived  according  to  a  documented  procedure.  (L2-23, 

All) 

This  procedure  typically  specifies  that: 

□  Critical  computer  resources  for  the  project  are  identified. 

□  Estimates  for  the  critical  computer  resources  are  related 
to  the  estimates  of: 

□  The  size  of  the  software  work  products. 

□  The  operational  processing  load. 

□  The  communications  traffic. 

□  Estimates  of  the  critical  computer  resources  are 
documented,  reviewed,  and  agreed  to. 

The  project's  software  schedule  is  derived  according  to  a 
documented  procedure.  (L2-23,  A12) 

This  procedure  typically  specifies  that: 

□  The  software  schedule  is  related  to: 

□  The  size  estimate  of  the  software  work  products  (or 
the  size  of  changes). 

□  The  software  effort  and  costs. 

□  The  software  schedule  is  based  on  past  experience. 

□  Similar  projects  are  used  when  possible. 

□  The  software  schedule  accommodates  the  imposed 
milestone  dates,  critical  dependency  dates,  and  other 
constraints. 

□  The  software  schedule  activities  are  of  appropriate 
duration  and  the  milestones  are  of  appropriate  time 
separation  to  support  accuracy  in  progress  measurement. 

□  Assumptions  made  in  deriving  the  schedule  are 
documented. 

□  The  software  schedule  is  documented,  reviewed,  and 
agreed  to. 
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Software  Project  Tracking  &  Oversight  (SPTO)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
project  tracking  and  oversight  process. 


T 

Documented  Procedures 

References 

The  project's  software  development  plan  is  revised  according 

to  a  documented  procedure.  (L2-33,  A2) 

This  procedure  typically  specifies  that: 

□  The  software  development  plan  is  revised,  as  appropriate, 
to  incorporate  plan  refinements  and  incorporate  plan 
changes,  particularly  when  plans  change  significantly. 

□  The  software  development  plan  is  updated  to  incorporate 
all  new  software  project  commitments  and  changes  to 
commitments. 

□  The  software  development  plan  is  reviewed  at  each 
revision. 

□  The  software  development  plan  is  managed  and 
controlled. 

Software  project  commitments  and  changes  to  commitments 
made  to  individuals  and  groups  external  to  the  organization 
are  reviewed  with  senior  management  according  to  a 
documented  procedure.  (L2-35,  A3) 

Fornial  reviews  to  address  the  accomplishments  and  results 
of  the  software  project  are  conducted  at  selected  project 
milestones  according  to  a  documented  procedure.  (L2-39. 
A13) 
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Software  Subcontract  Management  (SSM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process. 


4 

Documented  Procedures 

The  work  to  be  subcontracted  is  defined  and  planned  according  to  a 
documented  procedure.  (L2-47.  Al) 

This  procedure  typically  specifies  that: 

□  The  software  products  and  activities  to  be  subcontracted  are  selected 
based  on  a  balanced  assessment  of  both  technical  and  nontechnical 
characteristics  of  the  project. 

□  The  functions  or  subsystems  to  be  subcontracted  are  selected  to 
match  the  skills  and  capabilities  of  potential  subcontractors. 

□  The  specification  of  the  software  products  and  activities  to  be 
subcontracted  is  determined  based  on  a  systematic  analysis  and 
appropriate  partitioning  of  the  system  and  software 
requirements. 

□  The  specification  of  the  work  to  be  subcontracted  and  the  standards 
and  procedures  to  be  followed  are  derived  from  the  project's: 

□  statement  of  work, 

□  system  requirements  allocated  to  software, 

□  software  requirements, 

□  software  development  plan,  and 

□  software  standards  and  procedures. 

□  A  subcontract  statement  of  work  is: 

□  prepared, 

□  reviewed, 

□  agreed  to, 

□  revised  when  necessary,  and 

□  managed  and  controlled. 

□  A  plan  for  selecting  a  subcontractor  is  prepared  concurrent  with  the 
subcontract  statement  of  work  and  is  reviewed,  as  appropriate. 

Continued  on  next  page 
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Software 

Continued 


Documented 

procedures, 

continued 


Subcontract  Management  (SSM)  Procedures, 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

The  software  subcontractor  is  selected  based  on  an  evaluation  of  the 
subcontract  bidders'  ability  to  perform  the  woric,  according  to  a 
documented  procedure.  (L2-49,  A2) 

This  procedure  covers  the  evaluation  of: 

□  Proposals  submitted  for  the  planned  subcontract. 

□  Prior  performance  records  on  similar  woric,  if  available. 

□  The  geographic  locations  of  the  subcontract  bidders'  organizations 
relative  to  the  prime  contractor. 

□  Software  engineering  and  software  management  capabilities. 

□  Staff  available  to  perform  the  work. 

□  Prior  experience  in  similar  applications,  including  software  expertise 
on  the  subcontractor's  software  management  team. 

□  Available  resources. 

Changes  to  the  software  subcontractor's  statement  of  woric,  subcontract 
terms  and  conditions,  and  other  commitments  are  resolved  according  to 
a  documented  procedure.  (L2-51,  A6) 

This  procedure  typically  specifies  that: 

□  All  affected  groups  ot  Doth  the  prime  contractor  and  the 
subcontractor  are  involved. 

Continued  on  next  page 
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Software 

Continued 


Documented 

procedures, 

continued 


Subcontract  Management  (SSM)  Procedures, 


The  tabic  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


~T~ 

Documented  Procedures 

Formal  reviews  to  address  the  subcontractor's  software  engineering 

accomplishments  and  results  are  conducted  at  selected  milestones 

according  to  a  documented  procedure.  (L2-53,  A9) 

This  procedure  typically  specifies  that: 

□  Reviews  are  preplanned  and  documented  in  the  statement  of  woric. 

□  Reviews  address  the  subcontractor's  commitments  for,  plans  for,  and 
status  of  the  software  activities. 

□  Significant  issues,  action  items,  and  decisions  are  identified  and 
documented. 

□  Software  risks  are  addressed. 

□  The  subcontractor’s  software  development  plan  is  refined,  as 
appropriate. 

The  prime  contractor's  software  quality  assurance  group  monitors  the 
subcontractor's  software  quality  assurance  activities  according  to  a 
documented  procedure.  (L2-53,  A 10) 

This  procedure  typically  specifies  that: 

□  The  subcontractor's  plans,  resources,  procedures,  and  standards  for 
software  quality  assurance  are  periodically  reviewed  to  ensure  they 
are  adequate  to  monitor  the  subcontractor's  performance, 

□  Regular  reviews  of  the  subcontractor  are  conducted  to  ensure  the 
approved  procedures  and  standards  are  being  followed. 

□  The  prime  contractor's  software  quality  assurance  group  spot 
checks  the  subcontractor's  software  engineering  activities  and 
products. 

□  The  prime  contractor's  software  quality  assurance  group 
audits  the  subcontractor's  software  quality  assurance  records,  as 
appropriate. 

□  The  subcontractor's  records  of  its  software  quality  assurance 
activities  are  periodically  audited  to  assess  how  well  the  software 
quality  assurance  plans,  standards,  and  procedures  are  being 
followed. 

Continued  on  next  page 
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Software 

Continued 


Documented 

procedures, 

continued 


Subcontract  Management  (SSM)  Procedures, 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


~1~ 

Documented  Procedures 

Tlie  prime  contractor's  software  configuration  management  group 
monitors  the  subcontractor's  activities  for  software  configuration 
management  according  to  a  documented  procedure.  (L2-54,  A1 1) 

This  procedure  typically  specifies  that; 

□  The  subcontractor's  plans,  resources,  procedures,  and  standards  for 
software  cortfiguration  management  are  reviewed  to  ensure  they  are 
adequate. 

□  The  prime  contractor  and  the  subcontractor  coordinate  their 
activities  on  matters  relating  to  software  configuration  management 
to  ensure  that  the  subcontractor's  products  can  be  readily  integrated 
or  incorporated  into  the  project  environment  of  the  prime 
contractor. 

□  The  subcontractor's  software  baseline  library  is  periodically  audited 
to  assess  how  well  the  standards  and  procedures  for  software 
configuration  management  are  being  followed  and  how  effective 
they  are  in  managing  the  software  baseline. 

The  prime  contractor  conducts  acceptance  testing  as  part  of  the 
delivery  of  the  subcontractor's  software  products  according  to  a 
documented  procedure.  (L2-55,  A 12) 

This  procedure  typically  specifies  that: 

□  The  acceptance  procedures  and  acceptance  criteria  for  each  product 
are  defined,  reviev/ed,  and  approved  by  both  the  prime  contractor 
and  the  subcontractor  prior  to  the  test. 

□  The  results  of  the  acceptance  tests  are  documented. 

□  An  action  plan  is  established  for  any  software  product  that  does  not 
pass  its  acceptance  test. 
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Software  Quality  Assurance  (SQA)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
quality  assurance  process. 


T 

Documented  Procedures 

References 

A  SQA  plan  is  prepared  for  the  software  project  according 
to  a  documented  procedure.  0-2-63,  Al) 

This  procedure  typically  specifies  that: 

□  The  SQA  plan  is  developed  in  the  early  stages  of,  and  in 
parallel  with,  the  overall  project  planning. 

□  The  SQA  plan  is  reviewed  by  the  affected  groups  and 
individuals. 

□  The  SQA  plan  is  managed  and  controlled. 

Deviations  identified  in  the  software  activities  and  software 

work  products  are  documented  and  handled  according  to  a 

documented  procedure.  0-2-67,  A7) 

This  procedure  typically  specifies  that: 

□  Deviations  from  the  software  development  plan  and  the 
designated  project  standards  and  procedures  are 
documented  and  resolved  with  the  appropriate  software 
task  leaders,  software  managers,  or  project  manager, 
where  possible. 

□  Deviations  from  the  software  development  plan  and  the 
designated  project  standards  and  procedures  not 
resolvable  with  the  software  task  leaders,  software 
managers,  or  project  manager  are  documented  and 
presented  to  the  senior  manager  designated  to  receive 
noncompliance  items. 

□  Noncompliance  items  presented  to  the  senior  manager 
are  periodically  reviewed  imtil  they  are  resolved. 

□  The  documentation  of  noncompliance  items  is  managed 
and  controlled. 
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Software  Configuration  Management  (SCM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
configuration  management  process. 


T 

Documented  Procedures 

References 

A  SCM  plan  is  prepared  for  each  software  project  according 
to  a  documented  procedure.  (L2-76,  Al) 

This  procedure  typically  specifies  that: 

□  The  SCM  plan  is  developed  in  the  early  stages  of,  and  in 
parallel  with,  the  overall  project  planning. 

□  The  SCM  plan  is  reviewed  by  the  affected  groups. 

□  The  SCM  plan  is  managed  and  controlled. 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

Changes  to  baselines  are  controlled  according  to  a 

documented  procedure.  (L2-80,  A6) 

This  procedure  typically  specifies  that: 

□  Reviews  and/or  regression  tests  are  performed  to  ensure 
that  changes  have  not  caused  unintended  effects  on  the 
baseline. 

□  Only  configuration  items/units  that  are  approved  by  the 
SCCB  are  entered  into  the  software  baseline  library. 

□  Configuration  items/units  are  checked  in  and  out  in  a 
manner  that  maintains  the  correctness  and  integrity  of 
the  software  baseline  library. 

Products  from  the  software  baseline  library  are  created  and 
their  release  is  controlled  according  to  a  documented 
procedure.  (L2-80,  A7) 

This  procedure  typically  specifies  that: 

□  The  SCCB  authorizes  the  creation  of  products  from  the 
software  baseline  library. 

□  Products  from  the  .‘loftware-  baseline  library,  for  both 
interna!  and  external  use,  are  built  only  from 
configuration  items/units  in  the  software  baseline  library. 

Continued  on  next  page 


L2-Procedures-l2 


CMU/SEI-94-HB-1 


Software  Configuration  Management  (SCM)  Procedures, 

Continued 


Documented  The  table  below  lists  the  recommended  documented  procedures  for  the  software 
procedures,  configuration  management  process,  continued  from  die  previous  page, 
continued  _ _ 


Documented  Procedures 

References 

The  status  of  configuration  items/units  is  recorded  according 

to  a  documented  procedure.  (L2-80,  A8) 

This  procedure  typically  specifies  that: 

□  The  configuration  management  actions  are  recorded  in 
sufficient  detail  so  that  the  content  and  status  of  each 
configuration  item/unit  are  known  and  previous  versions 
can  be  recovered. 

□  The  current  status  and  history  (i.e.,  changes  and  other 
actions)  of  each  configuration  item/unit  are  maintained. 

Software  baseline  audits  are  conducted  according  to  a 

documented  procedure.  (L2-81,  A 10). 

This  procedure  typicJly  specifies  that: 

□  There  is  adequate  preparation  for  the  audit. 

□  The  integrity  cf  software  baselines  is  assessed. 

□  The  stmcture  and  facilities  of  the  configuration 
management  library  system  are  reviewed. 

□  The  completeness  and  correctness  of  the  software 
baseline  library  contents  are  verified. 

□  Compliance  with  applicable  SCM  standards  and 
procedures  is  verifi^. 

□  The  results  of  the  audit  arc  reported  to  the  project 
software  manager. 

□  Action  items  from  the  audit  are  tracked  to  closure. 
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Level  2  Summary 
Overview 


Section  purpose  The  purpose  of  this  section  is  to  provide  checklists  that  provide  a  summary  of  the 
repeatable  level  (level  2).  This  section  contains  three  perspectives  of  a  CMM  level. 

•  Key  process  area  (KPA)  specific  information: 

KPA  purpose 

KPA  goals 

•  Operational  framework  information  (from  a  maturity  level  viewpoint): 

Policies 

Standards 

Process  descriptions 

Procedures 

Training 

Tools 

•  Other  key  process  information  (from  a  maturity  level  viev.’point): 

Reviews  and  audits 

Work  products  managed  and  controlled 
Measurements 


Section  This  section  contains  the  following  topics, 

overview 


Topic 

Page 

Level  2  -  KPA  Purposes 

L2-Summary-2 

Level  2  -  KPA  Goals 

L2-Summary-3 

Level  2  -  Policies 

L2-Summary-5 

Level  2  -  Standards 

L2-Summary-6 

Level  2  -  Process  Descriptions 

L2-Summary-7 

Level  2  -  Procedures 

L2-Summary-10 

Level  2  -  Training 

L2-Summary-13 

Level  2  -  Tools 

L2-Summary-14 

Level  2  -  Reviews  and  Audits 

L2-Summary-15 

Level  2  -  Work  Products  Managed  and  Controlled 

L2-Summary-20 

Level  2  -  Measurements 

L2-Summary-21 
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Level  2  -  KPA  Purposes 


Level  2  KPA 
purposes 


The  following  table  describes  the  purpose  of  each  key  process  area  in  the  CMM  at 
level  2. 


nr 

KPA 

Purpose  of  KPAs  at  Level  2 

RM 

The  purpose  of  Requirements  Management  is  to  establish  a  common 
understanding  between  the  customer  and  the  software  project  of  the 
customer's  requirements  that  will  be  addressed  by  the  softw-are  project. 
(L2-1) 

SPP 

The  purpose  of  Software  Project  Planning  is  to  establish  reasonable 
plans  for  performing  the  software  engineering  and  for  managing  the 
software  project.  (L2-11) 

SPTO 

The  purpose  of  Software  Project  Tracking  and  Oversight  is  to  provide 
adequate  visibility  into  actual  progress  so  that  management  can  take 
effective  actions  when  the  software  project's  performance  deviates 
significantly  from  the  software  plans.  (L2-29) 

SSM 

The  purpose  of  Software  Subcontract  Management  is  to  select  qualified 
software  subcontractors  and  manage  them  effectively.  (L2-43) 

SQA 

The  purpose  of  Software  Quality  Assurance  is  to  provide  management 
with  appropriate  visibility  into  the  process  being  used  by  the  software 
project  and  of  the  products  being  built.  (L2-59) 

SCM 

The  purpose  of  Software  Configuration  Management  is  to  establish  and 
maintain  the  integrity  of  the  products  of  the  software  project  throughout 
the  project's  software  life  cycle.  (L2-71) 
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Level  2  KPA 
goals 


The  following  table  lists  the  goals  that  are  described  in  the  CMM  for  each  key  process 
area  at  level  2. 


KPA 

CMM  Goals  at  Level  2 

References 

RM 

System  requirements  allocated  to  software  are 
controlled  to  establish  a  baseline  for  software 
engineering  and  management  use.  (L2-2,  Gl) 

RM 

Software  plans,  products,  and  activities  are  kept 
consistent  with  the  system  requirements  allocated  to 
software.  (L2-2,  G2) 

SPP 

Software  estimates  are  documented  for  use  in  planning 
and  tracking  the  software  project.  (L2-12,  Gl) 

SPP 

Software  project  activities  and  commitments  are 
planned  and  documented.  (L2-12,  G2) 

SPP 

Affected  groups  and  individuals  agree  to  their 
commitments  related  to  the  software  project.  (L2-12, 
G3) 

SPTO 

Actual  results  and  performances  are  tracked  against  the 
software  plans.  (L2-30,  Gl) 

SPTO 

Corrective  actions  are  taken  and  managed  to  closure 
when  actual  results  and  performance  deviate 
significantly  from  the  software  plans.  (L2-30,  G2) 

L  .. 

SPTO 

Changes  to  software  commitments  are  agreed  to  by  the 
affected  groups  and  individuals.  (L2-30,  G3) 

SSM 

The  prime  contractor  selects  qualified  software 
subcontractors.  (L2-44,  Gl) 

SSM 

The  prime  contractor  and  the  software 
subcontractor  agree  to  their  commitments  to  each 
other.  (L2-44,G2) 

SSM 

The  prime  contractor  and  the  sofhvare 
subcontractor  maintain  ongoing  co'*’munications. 
(L2-44,  G3) 

SSM 

The  prime  contractor  tracks  the  software 
subcontractor’s  actual  results  and  performance  against 
its  conunitments.  (L2-44,  G4) 

Continued  on  next  page 
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Level  2  KPA  The  following  table  lists  the  goals  that  are  described  in  the  CMM  for  each  key  process 
goals,  continued  area  at  level  2,  continued  from  the  previous  page. 


References 


KPA 

CMM  Goals  at  Level  2 

SQA 

Software  quality  assurance  activities  are  planned.  (L2- 
60,  Gl) 

SQA 

Adherence  of  software  products  and  activities  to 
applicable  standards,  procedures,  and  requirements  is 
verified  objectively.  (L2-60,  G2) 

SQA 

Affected  groups  and  individuals  are  informed  of 
software  quality  assurance  activities  and  results.  (L2- 
60,  G3) 

SQA 

Noncompliance  issues  that  cannot  be  resolved  within 
the  software  project  are  addressed  by  senior 
management.  A.2-60,  G4) 

SCM 

Software  conJiguration  management  activities  are 
plarmed.  (L2-72,  Gl) 

SCM 

Selected  software  work  products  are  identified, 
controlled,  and  available.  (L2-72,  G2) 

SCM 

Changes  to  identified  software  work  products  are 
controlled.  (L2-72,G3) 

SCM 

Affected  groups  and  individuals  are  informed  of  the 
status  and  content  of  software  baselines.  (L2-72,  G4) 
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Level  2  policies  The  following  table  lists  the  recommended  policies  in  the  CMM  at  level  2. 


KPA 

Description 

RM 

Written  organizational  policy  for  managing  the  system 
requirements  allocated  to  software.  (L2-2,  Cl) 

SPP 

Written  organizational  policy  for  planing  a  software 
project.  (L2-12,  C2) 

SPTO 

Written  organizational  policy  for  managing  the 
software  project.  (L2-30,  C2) 

SSM 

Written  organizational  policy  for  managing  the 
software  subcontract.  ^2-44,  Cl) 

SQA 

Written  organizational  policy  for  implementing 
software  quality  assurance  (SQA).  ^2-60,  Cl) 

SCM 

Written  organizational  policy  for  implementing 
software  configuration  management  (SCM).  ^2-72, 
Cl) 

References 
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Level  2 
standards 


Reference 


The  CMM  recommends  the  contents  of  the  following  woik  products  at  level  2: 


KPA 

Standards  at  Level  2 

References 

RM 

Allocated  requirements.  (L2-4,  Ab2, 1-3) 

SPP 

Statement  of  work.  (L2-14,  Abl,  1) 

SPP 

Software  development  plan.  (L2-19,  A7. 1-10) 

SSM 

Contractual  agreement.  (L2-50,  A3, 1-8) 

SQA 

Software  quality  assurance  plan.  (L2-64,  A2, 1-10) 

SCM 

Software  configuration  management  plan.  (L2-77,  A2, 
1-2) 

Refer  to  the  Level  2  Standards  Checklists  for  additional  information  regarding  the 
content  of  each  standard. 
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RM  process 
description 


SPP  process 
description 


Requirements  Management  involves  establishing  and  maintaining  an  agreement  with 
the  customer  on  tlie  requirements  for  the  software  project.  This  agreement  is  referred 
to  as  tlie  "system  requirements  allocated  to  the  software."  The  "customer"  may  be 
interpreted  as  the  system  engineering  group,  the  marketing  group,  another  internal 
organization,  or  an  external  customer.  The  agreement  covers  both  the  technical  and 
nontechnical  (e.g.,  delivery  dates)  requirements.  The  agreement  forms  the  basis  for 
estimating,  planning,  performing,  and  tracking  the  software  project's  activities 
throughout  the  software  life  cycle. 

The  allocation  of  the  system  requirements  to  software,  hardware,  and  other  system 
components  (e.g.,  humans)  may  be  performed  by  a  group  external  to  the  software 
engineering  group  (e.g.,  the  system  engineering  group),  and  the  software  engineering 
group  may  have  no  direct  control  of  this  allocation.  Within  the  constraints  of  the 
project,  the  software  engineering  group  takes  appropriate  steps  to  ensure  that  the 
system  requirements  allocated  to  software,  which  they  are  responsible  for  addressing, 
are  documented  and  controlled. 

To  achieve  this  control,  the  software  engineering  group  reviews  the  initial  and  revised 
system  requirements  allocated  to  software  to  resolve  issues  before  they  are 
incorporated  into  the  software  project.  Whenever  the  system  requirements  allocated  to 
software  are  changed,  the  affected  software  plans,  work  products,  and  activities  are 
adjusted  to  remain  consistent  with  the  updated  requirements.  (L2-1) 


Software  Project  Planning  involves  developing  estimates  for  the  work  to  be 
performed,  establishing  the  necessary  commitments,  and  defining  the  plan  to  perform 
the  work. 

The  software  planning  begins  with  a  statement  of  the  work  to  be  performed  and  other 
constraints  and  goals  that  define  and  bound  the  software  project  (those  established  by 
the  practices  of  the  Requirements  Management  key  process  area).  The  software 
planning  process  includes  steps  to  estimate  the  size  of  the  software  work  products  and 
the  resources  needed,  produce  a  schedule,  identify  and  assess  software  risks,  and 
negotiate  commitments.  Iterating  through  these  steps  may  be  necessary  to  establish 
the  plan  for  the  software  project  O-e.,  the  software  development  plan). 

This  plan  provides  the  basis  for  performing  and  managing  the  software  project's 
activities  and  addresses  the  commitments  to  the  software  project's  customer  according 
to  the  resources,  constraints,  and  capabilities  of  the  software  project.  (L2-1 1) 
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SPTO  process 
description 


SSM  process 
description 


Software  Proj.?ct  Tracking  and  Oversight  involves  tracking  and  re’ dewing  the  software 
accomplishments  and  results  against  documented  estimates,  commitments,  and  plans, 
and  adjusting  these  plans  based  on  the  actual  accomplishments  and  results. 

A  documented  plan  for  the  software  project  (i.e.,  the  software  development  plan,  as 
described  in  the  Software  Project  Planning  key  process  area)  is  used  as  the  basis  for 
tracking  the  software  activities,  communicating  status,  and  revising  plans.  Software 
activities  are  monitored  by  the  management  Pwgress  is  primarily  determined  by 
comparing  the  actual  software  size,  effort,  cost,  and  schedule  to  the  plan  when  selected 
software  work  products  are  completed  and  at  selected  milestones.  When  it  is 
determined  that  the  software  project’s  plans  are  not  being  met  corrective  actions  are 
taken.  These  actions  may  include  revising  the  software  development  plan  to  reflect 
the  actual  accomplishments  and  replanning  the  remaining  work  or  taking  actions  to 
improve  the  performance.  (L2-29) 


Software  Subcontract  Management  involves  selecting  a  software  subcontractor, 
establishing  commitments  with  the  subcontractor,  and  tracking  and  reviewing  the 
subcontractor's  performance  and  results.  These  practices  cover  the  management  of  a 
software  (only)  subcontract,  as  well  as  the  management  of  the  software  component  of 
a  subcontract  that  includes  software,  hardware,  and  possibly  other  system  components. 

The  subcontractor  is  selected  based  on  its  ability  to  perform  the  work.  Many  factors 
contribute  to  the  decision  to  subcontract  a  portion  of  the  prime  contractor’s  woric. 
Subcontractors  may  be  selected  based  on  strategic  business  alliances,  as  well  as 
technical  considerations.  The  practices  of  this  key  process  area  address  the  traditional 
acquisition  process  associated  with  subcontracting  a  defined  portion  of  the  work  to 
another  organization. 

When  subcontracting,  a  documented  a^eement  covering  the  technical  and 
nontechnical  (e.g.,  delivery  dates)  requirements  is  established  and  is  used  as  the  basis 
for  managing  the  subcontract.  The  work  to  be  done  by  the  subcontractor  and  the  plans 
for  the  work  are  documented.  The  standards  that  are  to  be  followed  by  the 
subcontractor  are  compatible  with  the  prime  contractor’s  standards. 

The  software  planning,  tracking,  and  oversight  activities  for  the  STibcontracted  work 
are  performed  by  the  subcontractor.  The  prime  contractor  ensures  that  these  planning, 
tracking,  and  oversight  activities  are  performed  appropriately  and  that  the  software 
products  delivered  by  the  subcontractor  satisfy  their  acceptance  criteria.  The  prime 
contractor  works  with  the  subcontractor  to  manage  their  product  and  process 
interfaces.  (L2-43) 


Continued  on  next  page 
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SQA  process 
description 


SCM  process 
description 


Software  Quality  Assurance  involves  reviewing  and  auditing  the  software  products 
and  activities  to  verify  that  they  comply  with  the  applicable  procedures  and  standards 
and  providing  the  software  project  and  other  appropriate  managers  with  the  results  of 
these  reviews  and  audits. 

The  software  quality  assurance  group  works  with  the  software  project  during  its  early 
stages  to  establish  plans,  standards,  and  procedures  that  will  add  value  to  the  software 
project  and  satisfy  the  constraints  of  the  project  and  the  organization's  policies.  By 
participating  in  establishing  the  plans,  standards,  and  proce  lures,  the  software  quality 
assurance  group  helps  ensure  they  fit  the  project's  needs  and  verifies  tliat  they  will  be 
usable  for  performing  reviews  and  audits  throughout  the  software  life  cycle.  The 
software  quality  assurance  group  reviews  project  activities  and  audits  software  work 
products  throughout  the  life  cycle  and  provides  management  with  visibility  as  to 
whether  the  software  project  is  adhering  to  its  established  plans,  standards,  and 
procedures. 

Compliance  issues  are  first  addressed  within  the  software  project  and  resolved  there  if 
possible.  For  issues  not  resolvable  within  the  software  project,  tire  software  quality 
assurance  group  escalates  th'’,  issue  to  an  appropriate  level  of  management  for 
resolution. 

This  key  process  area  covers  the  practices  for  the  group  performing  the  software 
quality  assurance  function.  The  practices  identifying  the  specific  activities  and  work 
products  that  the  software  quality  assurance  group  reviews  and/or  audits  are  generally 
contained  in  the  Verifying  Implementation  common  feature  of  the  other  key  process 
areas.  (L2-59) 


Software  Configuration  Management  involves  identifying  the  configuration  of  the 
software  (i.e.,  selected  software  work  products  and  their  descriptions)  at  given  points 
in  time,  systematically  controlling  changes  to  the  configuration,  and  maintaining  the 
integrity  and  traceability  of  the  configuration  throughout  the  software  life  cycle.  The 
work  products  placed  under  software  configuration  management  include  the  software 
products  that  are  delivered  to  the  customer  (e.g.,  the  software  requirements  document 
and  the  code)  and  the  items  that  are  identified  with  or  required  to  create  these  software 
products  (e.g.,  the  compiler). 

A  software  baseline  library  is  established  contairting  the  software  baselines  as  they  are 
developed.  Changes  to  baselines  and  the  release  of  software  products  built  from  the 
software  baseline  library  are  systematically  controlled  via  the  change  control  and 
configuration  auditing  Actions  of  software  configuration  management. 

This  key  process  area  covers  the  practices  for  performing  the  software  configuration 
management  function.  The  practices  identifying  specific  configuration  items/units  are 
contained  in  the  key  process  areas  that  describe  the  development  and  maintenance  of 
each  configuration  item/unit.  (L2-71) 
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Level  2  -  Procedures 


Level  2 
procedures 


The  table  below  lists  the  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  2.  Refer  to  the  Level  2  Procedure 
Checklists  for  additional  information  regarding  the  content  of  each  documented 
procedure. 


KPA 

Documented  Procedures 

References 

RM 

ITiere  are  no  required  procedures  for  the  RM  process. 

SPP 

Software  project  commitments  made  to  individuals  and 
groups  external  to  the  organization  are  reviewed  with 
senior  management  according  to  a  documented 
procedure.  (L2-17,  A4) 

SPP 

The  project's  software  development  plan  is  developed 
according  to  a  documented  procedure.  (L2-18,  A6) 

SPP 

Estimates  for  the  size  of  the  software  work  products 
(or  changes  to  the  size  of  software  work  products)  are 
derived  according  to  a  documented  procedure.  (L2-21 , 
A9) 

SPP 

Estimates  for  the  software  project’s  effort  and  costs  are 
derived  according  to  a  documented  procedure.  (L2-22, 
AIO) 

SPP 

Estimates  for  the  project's  critical  computer  resources 
are  derived  according  to  a  documented  procedure. 
(L2-23,A11) 

SPP 

The  project’s  software  schedule  is  derived  according  to 
a  documented  procedure.  (L2-23,  A 12) 

SPTO 

The  project's  software  development  plan  is  revised 
according  to  a  documented  procedure.  (L2-33,  A2) 

SPTO 

Software  project  commitments  and  changes  to 
commitments  made  to  individuals  and  groups  external 
to  the  organization  are  reviewed  with  senior 
management  according  to  a  documented  procedure. 
(L2-35,  A3) 

SPTO 

Formal  reviews  to  address  the  accomplishments  and 
results  of  the  software  project  are  conducted  at  selected 
project  milestones  according  to  a  documented 
procedure.  (L2-39,  A13) 

Continued  on  next  page 
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Level  2  -  Procedures,  continued 


Level  2 

procedures, 

continued 


The  table  below  lists  the  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  2,  continued  from  the  previous  page. 


'~T 

KPA 

Documented  Procedures 

References 

SSM 

The  work  to  be  subcontracted  is  defined  and  planned 
according  to  a  documented  procedure.  (L2-47,  Al) 

SSM 

The  software  subcontractor  is  selected  based  on  an 
evaluation  of  the  subcontract  bidders’  ability  to 
perform  the  woric,  according  to  a  documented 
procedure.  (L2-49,  A2) 

SSM 

Changes  to  the  software  subcontractor’s  statement  of 
woric,  subcontract  terms  and  conditions,  and  other 
commitments  are  resolved  according  to  a  documented 
procedure.  (L2-51,A6) 

SSM 

Formal  reviews  to  address  the  subcontractor’s  software 
engineering  accomplishments  and  results  are 
conducted  at  selected  milestones  according  to  a 
documented  procedure.  (L2-53,  A9) 

SSM 

The  prime  contractor's  software  quality  assurance 
group  monitors  the  subcontractor’s  software  quality 
assurance  activities  according  to  a  documented 
procedure.  (L2-53,  AlO) 

SSM 

The  prime  contractor's  software  configuration 
management  group  monitors  the  subcontractor’s 
activities  for  software  configuration  management 
according  to  a  documented  procedure.  (L2-54,  Al  1) 

SSM 

The  prime  contractor  conducts  acceptance  testing  as 
part  of  the  delivery  of  the  subcontractor's  software 
products  according  to  a  documented  procedure.  (L2- 
55,  A12) 

SQA 

A  SQA  plan  is  prepared  for  the  software  project 
according  to  a  documented  procedure.  (L2-63,  Al) 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L2-Summary-11 


Level  2  -  Procedures,  continued 


Level  2 

procedures, 

continued 


The  table  below  lists  die  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  2,  continued  from  the  previous  page. 


KPA 

Documented  Procedures 

References 

SQA 

Deviations  identified  in  the  software  activities  and 
software  work  products  are  documented  and  handled 
according  to  a  documented  procedure.  (L2-67,  A7) 

SCM 

A  SCM  plan  is  prepared  for  each  software  project 
according  to  a  documented  procedure.  (L2-76,  Al) 

SCM 

Change  requests  and  problem  reports  for  all 
configuration  items/units  are  initiated,  recorded, 
reviewed,  approved,  and  tracked  according  to  a 
documented  procedure.  (L2-79,  A5) 

SCM 

Changes  to  baselines  are  controlled  according  to  a 
documented  procedure.  OL.2-80,  A6) 

SCM 

Products  from  the  software  baseline  library  are  created 
and  their  release  is  controlled  according  to  a 
documented  procedure.  (L2-80,  Al) 

SCM 

The  status  of  configuration  itemsAinits  is  recorded 
according  to  a  documented  procedure  (L2-80,  A8) 

SCM 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10). 
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Level  2  training  The  table  below  lists  the  training  recommended  in  the  CMM  at  level  2. 


KPA 

Training 

RM 

Members  of  the  software  engineering  group  and 
oilier  software-related  groups  are  trained  to  perform 
their  requirements  management  activities.  (L2-i',  Ab4) 

SPP 

The  software  managers,  software  engineers,  and 
other  individuals  involved  in  the  software  project 
planning  are  trained  in  the  software  estimating  and 
planning  procedures  applicable  to  their  areas  of 
responsibility.  (L2-16,  Ab4) 

SPTO 

The  software  managers  are  trained  in  managing  the 
technical  and  personnel  aspects  of  the  software  project. 
(L2-32,  Ab4) 

SPTO 

First-line  software  managers  receive  orientation  in 
the  technical  aspects  of  the  software  project.  (L2-32, 
Ab5) 

SSM 

Software  managers  and  other  individuals  who  are 
involved  in  establishing  and  managing  the  software 
subcontract  are  trained  to  perform  these  activities. 
(L2-46,  Ab2) 

SSM 

Software  managers  and  other  individuals  who  are 
involved  in  managing  the  software  subcontract  receive 
orientation  in  the  technical  aspects  of  the  subcontract. 
(L2-46,  Ab3) 

SQA 

Members  of  the  SQA  group  are  trained  to  perform 
their  SQA  activities.  (5.2-62,  Ab3) 

SQA 

The  members  of  the  software  project  receive 
orientation  on  the  role,  responsibilities,  authority,  and 
value  of  the  SQA  group.  (L2-63,  Ab4) 

SCM 

Members  of  the  SCM  group  are  trained  in  the 
objectives,  procedures,  and  methods  for  performing 
their  SCM  activities.  ^2-76,  Ab4) 

SCM 

Members  of  the  software  engineering  group  and 
other  software-related  groups  are  trained  to  perform 
their  SCM  activities.  (L2-76,  AbS) 

References 
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Level  2  tools  The  table  below  lists  the  tools  recommended  in  the  CMM  for  level  2. 


~T 

KPA 

Tools 

References 

RM 

Tools  to  support  the  activities  for  managing 
requirements.  (L2-5,  Ab3, 2) 

SPP 

Tools  to  support  software  project  planning  activities. 
(L2-16,  Ab3, 2) 

SPTO 

Tools  to  support  software  tracking.  (L2-32,  Ab3, 2) 

SSM 

Tools  to  support  managing  the  subcontract.  (L2-46, 
Abl,  2) 

SQA 

Tools  to  support  the  SQA  activities.  (L2-62,  Ab2, 3) 

SCM 

Tools  to  support  the  SCM  activities.  (L2-75,  Ab3, 2) 

SCM 

A  configuration  management  library  system  is 

established  as  a  repository  for  the  software  baselines. 

(L2-77,  A3) 

This  library  system; 

□  Supports  multiple  control  levels  of  SCM. 

□  Provides  for  the  storage  and  retrieval  of 
configuration  items/units. 

□  Provides  for  the  sharing  and  transfer  of 
configuration  items/units  between  the  affected 
groups  and  between  control  levels  within  the 
libraiy. 

□  Helps  in  the  use  of  product  standards  for 
configuration  item^units. 

□  Provides  for  the  storage  and  recovery  of  archive 
versions  of  configuration  items/units. 

□  Helps  to  ensure  correct  creation  of  products  from 
the  software  baseline  library. 

□  Provides  for  the  storage,  update,  and  retrieval  of 
SCM  records. 

□  Supports  production  of  SCM  reports. 

□  Provides  for  the  maintenance  .-f  the  library 
structure  and  contents. 
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Level  2  -  Reviews  and  Audits 


Level  2  reviews 
and  audits 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2. 


KPA 

Review  or  Audit 

Review 

Participants 

References 

RM 

The  software  engineering  group 
reviews  allocated  requirements  before 
they  are  incorporated  into  the  software 
project.  (L2-5,  Al) 

Software 

engineering 

group 

RM 

Changes  to  the  allocated  requirements 
are  reviewed  and  incorporated  into  the 
software  project.  (L2-7,  A3) 

Not  specified 
in  CMM 

RM 

The  activities  for  managing  the 
allocated  requirements  are  reviewed 
with  senior  management  on  a 
periodic  basis.  (L2-9,  VI) 

Senior 

management 

RM 

The  activities  for  managing  the 
allocated  requirements  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
9,  V2) 

Project 

manager 

RM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
managing  the  allocated  requirements 
and  reports  the  results.  (L2-9,  V3) 

SQA  group 

SPP 

Software  project  commitments  made 
to  individuals  and  groups  external  to 
the  organization  are  reviewed  with 
senior  management.  (L2-17,  A4) 

Senior 

management 

SPP 

The  activities  for  software  project 
planning  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2- 
26,  VI) 

Senior 

management 

SPP 

The  activities  for  software  project 
planning  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  basis.  (L2-26,  V2) 

Project 

manager 

Continued  on  next  page 
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Level  2  -  Reviews  and  Audits,  continued 


Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continued  from  the  previous  page. 


~T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SPP 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
software  project  planning  and  reports 
the  results  (1.2-27,  V3) 

SQA  group 

SPTO 

Software  project  commitments  and 
changes  to  commitments  made  to 
individuals  and  groups  external  to 
the  organization  are  reviewed  with 
senior  management  according  to  a 
documented  procedure.  (L2-35,  A3) 

Senior 

management 

SPTO 

The  software  engineering  group 
conducts  periodic  internal  reviews  to 
track  technical  progress,  plans, 
performance,  a^  issues  against  the 
software  development  plan.  (L2-38, 
A12) 

These  reviews  are  conducted  between: 

□  The  first-line  software  managers 
and  their  software  task  leaders. 

□  The  project  software  manager, 
first-line  software  managers,  and 
other  software  managers,  as 
appropriate. 

Software 

engineering 

group 

First-line 

software 

managers 

Project 

software 

manager 

Software 

managers 

Software  task 
leaders 

SPTO 

Formal  reviews  to  address  the 
accomplishments  and  results  of  tlie 
software  project  are  conducted  at 
selected  project  milestones  according 
to  a  documented  procedure,  (L2-39, 
A13) 

□  These  reviews  are  conducted  with 
the  customer,  end  user,  and 
affected  groups  within  the 
organization,  as  appropriate.  (L2- 
39,  A 13, 2) 

Affected 

groups 

Customer 

End  user 

Software 

managers 

SPTO 

The  activities  for  software  project 
tracking  and  oversight  are  reviewed 
with  senior  management  on  a 
periodic  basis.  (L2-40,  VI) 

Senior 

management 

Continued  on  next  page 
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Level  2  -  Reviews  and  Audits,  continued 


Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continued  from  the  previous  page. 


4 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SPTO 

The  activities  for  software  project 
tracking  and  oversight  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
41,  V2) 

Project 

manager 

SPTO 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
software  project  tracking  and  oversight 
and  reports  the  results.  (L2-41,V3) 

SQA  group 

SSM 

A  documented  subcontractor’s 
software  development  plan  is  reviewed 
and  approved  by  the  prime 
contractor.  (L2-51,A4) 

Prime 

contractor 

SSM 

The  prime  contractor's  management 
conducts  periodic  status/coordination 
reviews  with  the  software 
subcontractor's  management.  (L2- 
51,  A7) 

Prime 

contractor's 

management 

Sub¬ 

contractor's 

management 

SSM 

Periodic  technical  reviews  and 
interchanges  are  held  with  the 
software  subcontractor.  (L2-52,  A8) 

Software 

subcontrac¬ 

tor 

SSM 

Formal  reviews  to  address  the 
subcontractor’s  software  engineering 
accomplishments  and  results  are 
conducted  at  selected  milestones 
according  to  a  documented  procedure. 
(L2-53,  A9) 

Not  specified 
in  the  CMM 

SSM 

The  software  subcontractor’s 
performance  if.  evaluated  on  a  periodic 
basis,  and  the  evaluation  is  reviewed 
with  the  subconi’-actor.  (L2-55,  A13) 

Subcontrac¬ 

tor 

Continued  on  next  page 
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Level  2  -  Reviews  and  Audits,  continued 


Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continued  from  the  previous  page. 


T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SSM 

The  activities  for  managing  the 
software  subcontract  are  reviewed 
with  senior  management  on  a 
periodic  basis.  (L2-56,  VI) 

Senior 

management 

SSM 

Tlie  activities  for  managing  the 
software  subcontract  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
56,  V2) 

Project 

manager 

SSM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
managing  the  software  subcontract  and 
reports  the  results.  (L2-57,  V3) 

SQA  group 

SQA 

The  SQA  group  participates  in  the 
preparation  and  review  of  the  project's 
software  development  plan,  standards, 
and  procedures.  (L2-65,  A3) 

SQA  group 

SQA 

The  SQA  group  reviews  the  software 
engineering  activities  to  verify 
compliance.  (L2-66,  A4) 

SQA  group 

SQA 

The  SQA  group  audits  designated 
software  work  products  to  verify 
compliance.  (L2-66,  A5) 

SQA  group 

SQA 

The  SQA  group  conducts  periodic 
reviews  of  its  activities  and  findings 
with  the  customer's  SQA  personnel, 
as  appropriate.  (L2-67,  A8) 

SQA  group 

Customer’s 

SQA 

personnel 

SQA 

The  SQA  activities  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L2-68,V1) 

Senior 

management 

Continued  on  next  page 
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Level  2  -  Reviews  and  Audits,  Continued 


Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continut.i  from  the  previous  page. 


'T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SQA 

The  SQA  activities  are  reviewed  with 
the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
69,  V2) 

Project 

manager 

SQA 

Experts  independent  of  the  SQA 
group  periodically  review  the 
activities  and  software  work  products 
of  the  project's  SQA  group.  (L2-69, 
V3) 

Experts 
independent 
of  the  SQA 
group 

SCM 

Change  requests  and  problem  reports 
for  all  configuration  items/units  are 
initiated,  recorded,  reviewed, 
approved,  and  tracked  according  to  a 
documented  procedure.  (L2-79,  A5) 

Not  specified 
in  CMM 

SCM 

Software  baseline  audits  are  conducted 
according  to  a  documented  procedure. 
(L2-8I,A10) 

Not  specified 
in  CMM 

SCM 

The  SCM  activities  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L2-82,V1) 

Senior 

management 

SCM 

The  SCM  activities  are  reviewed  with 
the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
83,  V2) 

Project 

manager 

SCM 

The  SCM  group  periodically  audits 
software  baselines  to  verify  that  they 
conform  to  the  documentation  that 
defines  them.  (L2-83,  V3) 

SCM  group 

SCM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for  SCM 
and  reports  the  results.  (L2-83,  V4) 

SQA  group 

CMU/SEI-94-HB-1 


L2-Summary-19 


Level  2  -  Work  Products  Managed  and  Controlled 


Level  2  work 
products 
managed  and 
controlled 


The  table  below  lists  the  woric  products  that  are  recommended  to  be  managed  and 
controlled  in  the  CMM  at  level  2. 


~T 

KPA 

Work  Products  Managed  and  Controlled 

References 

RM 

Allocated  requirements.  (L2-7,  A2, 1) 

SPP 

Project's  software  development  plan.  (L2-13,  C2, 6) 

SPP 

Statement  of  woilc.  (L2-ir>.  Abl,  3) 

SPP 

Software  planning  data.  (L2-25,  A15, 2) 

SPTO 

Software  development  plan  (SDP).  (L2-34,  A2, 4) 
(Same  as  project’s  SDP  above  in  SPP) 

SPTO 

Software  replanning  data.  (L2-38,  A1 1 , 2) 

SSM 

Subcontract  statement  of  woric.  (L2-48,  A1 ,  3.5) 

SQA 

SQA  plan.  (L2-64,  Al,  3) 

SQA 

Documentation  of  noncompliance  items.  (L2-67,  A7, 

4) 

SCM 

SCM  plan.  (L2-77,A1,3) 
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Level  2  -  Measurements 


Level  2 
measurements 


The  table  below  describes  the  recommended  measurements  in  the  CMM  at  level  2. 


V 

KPA 

Description 

References 

RM 

Measurements  to  determine  the  status  of  the  activities 
for  managing  the  allocated  requirements.  (L2-8,  M 1 ) 

SPP 

Software  planning  data.  (L2-25,  A15) 

□  Information  recorded  includes  the  estimates  and 
the  associated  information  needed  to  reconstruct 
the  estimates  and  assess  their  reasonableness.  (L2- 
25,A15,  1) 

SPP 

Measurements  to  determine  the  status  of  the  software 
planning  activities.  (L2-25,  Ml) 

SPTO 

.Actual  measurement  data  and  replanning  data  for  the 
software  project.  (L2-38,  All) 

SPTO 

Measurements  to  determine  the  status  of  the  software 
tracking  and  oversight  activities.  (L2-39,  Ml) 

SSM 

Measurements  to  determine  the  status  of  the  activities 
for  managing  the  software  subcontract.  (L2-55,  MI) 

SQA 

Measurements  to  determine  the  cost  and  schedule 
status  of  the  SQA  activities.  (L2-68,  Ml) 

SCM 

Measurements  to  determine  the  status  of  the  SCM 
activities.  (L2-82,  Ml) 
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Chapter  5.  Defined  Level  (Level  3) 

Overview 

Introduction  This  chapter  contains  the  checklists  for  level  3  of  the  CMM. 

In  this  chapter  This  chapter  contains  the  following  sections: 

Section  Title 

Page 

Level  3  Policy  Checklists 

L3-Policy-l 

Level  3  Standards  Checklists 

L3-Standards-1 

Level  3  Process  Checklists 

L3-Process-l 

Level  3  Procedure  Checklists 

L3-Procedures-l 

Level  3  Summary 

L3-Summary-1 
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Level  3  Policy  Checklists 
Overview 


Introduction 


Purpose 


Checklist 

description 


In  this  section 


This  section  describes  the  explicit  policies  found  in  the  Capability  Maturity  Model 
at  maturity  level  3. 


The  purpose  of  the  policy  checklists  is  to  provide: 

•  Guidance  in  identifying  which  policies  are  recommended  by  the  CMM  at  level  3. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  policies  to  determine 
if  they  are  consistent  with  the  CMM  at  level  3. 

•  Information  that  can  be  used  to  develop  software  policies  so  that  they  are 
consistent  with  the  CMM  at  level  3. 


Each  checklist  ccntains  two  subsections:  the  KPA  policies  and  the  KPA  goals.  The 
table  below  describes  these  two  subsections  of  a  policy  checklist. 


Subsection 

Description 

Policy  checklist 

This  subsection  contains  criteria  that  the  organizational 
policy  can  be  evaluated  against.  These  criteria  must  be 
addressed  by  organizational  policy  to  be  consistent  with  the 
CMM. 

Policy  goals 

This  subsection  is  a  reminder  to  policy  designers  and 
evaluators  to  keep  in  mind  the  KPA  goals  when  developing 
the  policies  for  each  KPA.  The  goals  can  be  thought  of  as 
the  results  of  implementing  an  effective  pobcy.. 

This  section  covers  the  following  policies: 


Policies 

See  Page 

Organization  process  focus  policy 

L3-Policy-2 

Organization  process  definition  policy 

L3-Policy-3 

Training  program  policy 

L3-Policy-4 

Integrated  software  management  policy 

L3-Policy-5 

Software  product  engineering  policy 

L3-Policy-6 

Intergroup  coordination  policy 

L3-Policy-7 

Peer  reviews  policy 

L3-Policy-8 
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Organization  Process  Focus  (OPF)  Policy 


OPF  policy 
checklist 


OPF  policy 
goals 


The  organization  follows  a  written  organizational  policy  for  coordinating  software 
process  development  and  improvement  activities  across  the  organization  (L3-2, 
Cl).  This  policy  typically  specifies  that: 


Description 

References 

A  group  is  established  that  is  responsible  for  the 
organization-level  software  process  activities  and 
coordinating  these  activities  with  the  projects.  (L3-2,  Cl,  1) 

The  software  processes  used  by  the  projects  are  assessed 
periodically  to  determine  their  strengths  and  weaknesses. 
(L3-2,  Cl,  2) 

The  software  processes  used  by  the  projects  are 
appropriately  tailored  from  the  organization’s  standard 
software  process.  (L3-2,  Cl,3) 

Improvements  to,  and  other  useful  information  on,  each 
project’s  software  process,  tools,  and  methods  are  available 
to  other  projects.  (L3-2,  Cl,  4) 

Implementation  of  an  effective  organizational  process  focus  policy  has  the 
following  results: 


V 

Results  of  Effectively  Implementing  OPF  Policy 

References 

Software  process  development  and  improvement  activities 
are  coordinated  across  the  organization.  (L3-1,  Gl) 

The  strengths  and  weaknesses  of  the  software  processes  used 
are  identified  relative  to  the  process  standard.  (L3-2,  G2) 

Organization-level  process  development  and  improvement 
activities  are  planned.  (L3-2,  G3) 

L3-Policy-2 
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Organization  Process  Definition  (OPD)  Policy 


OPD  policy 
checklist 


OPD  policy 
goals 


The  organization  follows  a  written  policy  for  developing  and  maintaining  a 
standard  software  process  and  related  process  assets  (L3^-12,  Cl).  This  policy 
typically  specifies  that; 


V 

Description 

References 

A  standard  software  process  is  defined  for  the  organization. 
(L3-12,  Cl,  1) 

A  project’s  defined  software  process  is  a  tailored  version  of 
the  organization’s  standard  software  process.  (L3-13,  Cl,  2) 

The  organization’s  software  process  assets  are  maintained. 
(L3-13,  Cl,  3) 

Information  collected  from  the  projects  is  organized  and 
used  to  improve  the  organization’s  standard  software 
process.  (L3-13,  Cl,4) 

Implementation  of  an  effective  organizational  process  definition  policy  has  the 
following  results; 


V 

Results  of  Effectively  Implementing  OPD  Policy 

References 

A  standard  software  process  for  the  organization  is 
developed  and  maintained.  (L3-12,  Gl) 

Information  related  to  the  use  of  the  organization’s  standard 
software  process  by  the  software  projects  is  collected, 
reviewed,  and  made  available.  (L3-12,  G2) 
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Training  Program  (TP)  Policy 


TP  policy 
checklist 


TP  policy  goals 


The  organization  follows  a  written  policy  for  meeting  its  training  needs  (L3-26, 
Cl).  This  policy  typically  specifies  that: 


Description 

References 

The  needed  skills  and  knowledge  for  each  software 
management  and  technical  role  are  identified.  (L3-26,  Cl, 

1) 

Training  vehicles  for  imparting  skills  and  knowledge  are 
identified  and  approved.  (L3-26,  Cl,  2) 

Training  is  provided  to  build  the  skill  base  of  the 
organization,  to  fill  the  specific  needs  of  the  projects,  and  to 
develop  the  skills  of  individuals.  (L3-26,  Cl,  3) 

Training  is  developed  within  the  organization  or  obtained 
from  outside  the  organization  when  appropriate.  (L3-26, 

Cl,  4) 

Implementation  of  an  effective  training  program  policy  has  the  following  results: 


V 

Results  of  Effectively  Implementing  TP  Policy 

References 

Training  activities  are  planned.  (L3-25,  Gl) 

1 

Training  for  developing  the  skills  and  knowledge  needed  to 
perform  software  management  and  technical  roles  is 
provided.  (L3-25,  G2) 

1 

Individuals  in  the  software  engineering  group  and 
software-related  groups  receive  the  training  necessary  to 
perform  their  roles.  (L3-26,  G3) 

L3-Policy-4 
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Integrated  Software  Management  (ISM)  Policy 


ISM  policy 
checklist 


ISM  policy 
goals 


The  project  follows  a  written  organizational  policy  requiring  that  the  software 
project  be  planned  and  managed  using  the  organization's  standard  software  process 
and  related  process  assets  (L3-38,  C!).  This  policy  typically  specifies  that: 


V 

Description 

References 

Each  project  documents  the  project's  defined  software 
process  by  tailoring  the  organization's  standard  software 
process.  (L3-39,  Cl,l) 

The  project's  deviations  from  the  organization's  standard 
software  process  are  documented  and  approved.  (L3-39,  Cl, 
2) 

Each  project  performs  its  software  activities  in  accordance 
with  the  project's  defined  software  process.  (L3-39,  Cl,  3) 

Each  project  collects  and  stores  appropriate  project 
measurement  data  in  the  organization's  software  process 
database.  (L3-39,  Cl,4) 

Implementation  of  an  effective  integrated  software  management  policy  has  the 
following  results: 


Results  of  Effectively  Implementing  ISM  Policy 

References 

The  project's  defined  software  process  is  a  tailored  version  of 
the  organization's  standard  software  process.  (L3-38,  Gl) 

The  project  is  planned  and  managed  according  to  the 
project's  defined  software  process,  (L3-38,  G2) 
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Software  Product  Engineering  (SPE)  Policy 


SPE  policy 
checklist 


SPE  policy 
goals 


The  project  follows  a  written  organizational  policy  for  performing  the  software 
engineering  activities  (L3-60.  Cl).  This  policy  typically  specifies  that: 


V 

Description 

References 

The  software  engineering  tasks  are  performed  in  accordance 
with  the  project’s  defined  software  process.  (L3-60,  Cl,  1) 

Appropriate  methods  and  tools  are  used  to  build  and 
maintain  the  software  products.  (L3-60,  Cl,  2) 

The  software  plans,  tasks,  and  products  are  traceable  to  the 
system  requirements  allocated  to  software.  (L3-60,  Cl,  3) 

Implementation  of  an  effective  software  product  engineering  policy  has  the 
following  results; 


V 

Results  of  Effectively  Implementing  SPE  Policy 

References 

The  software  engineering  tasks  are  defined,  integrated,  and 
consistently  performed  to  produce  the  software.  (L3-60, 

Gl) 

Software  work  products  are  kept  consistent  with  each  other. 
(L3-60,  G2) 

L3-Policy-6 
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Intergroup  Coordination  (1C)  Policy 


IC  policy  The  project  follows  a  written  organizational  policy  for  establishing 

checklist  interdisciplinary  engineering  teams  (L3-84,  Cl).  This  policy  typically  specifies 

that: 


Description 

References 

The  system  requirements  and  project-level  objectives  for  the 
project  are  defined  and  reviewed  by  all  affected  groups. 
(L3-84,  Cl,  1) 

The  engineering  groups  coordinate  their  plans  and 
objectives.  (L3-84,  Cl,2) 

Managers  are  responsible  for  establishing  and  inaintaining 
an  environment  to  facilitate  interaction,  coordination, 
support,  and  teamwork  between  the  project  s  engineering 
groups,  between  the  project  and  the  customer  or  end  users, 
as  appropriate,  and  throughout  the  organization.  (L3-85, 

Cl,  3) 

IC  policy  goals  Implementation  of  an  effective  intergroup  coordination  policy  has  the  following 
results: 
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L3-Policy-7 


Peer  Reviews  (PR)  Policy 


PR  policy  The  project  follows  a  written  organizational  policy  for  performing  peer  reviews 

checklist  (L3-94,  Cl).  This  policy  typically  specifies  that: 


Description 

References 

The  organization  identifies  a  standard  set  of  software  work 
products  that  will  undergo  peer  review.  (L3-94,  Cl,  1) 

Each  project  identifies  the  software  work  products  that  will 
undergo  peer  review.  (L3-94,  Cl,  2) 

Peer  reviews  are  led  by  trained  peer  review  leaders.  (L3-94, 
Cl,  3) 

Peer  reviews  focus  on  the  software  work  product  being 
reviewed  and  not  on  the  producer.  (L3-94,  Cl,  4) 

Results  of  the  peer  reviews  are  not  used  by  management  to 
evaluate  the  performance  of  individuals.  (L3-94,  Cl,  5) 

PR  policy  goals  Implementation  of  an  effective  Peer  Reviews  policy  has  the  following  results: 


II 

Results  of  Effectively  Implementing  PR  Policy 

References 

Peer  reviews  are  planned.  (L3-93,  Gl) 

Defects  in  the  software  work  products  are  identified  and 
removed.  (L3-93,  G2) 

L3-Policy-8 
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Level  3  Standards  Checklists 
Overview 


Introduction 


Definition 


Purpose 


What  the 
standards 
checklists  are 
not 


This  section  describes  the  recommended  content  of  selected  work  products  in  the 
CMM  at  maturity  level  3. 


A  standard  checklist  describes  the  content  of  a  work  product  as  recommended  by 
the  CMM. 


The  purpose  of  the  standards  checklists  is  to  provide; 

•  Guidance  in  identifying  the  contents  of  standard  work  products  that  are 
recommended  by  the  CMM  at  level  3. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  standards  to 
deiermine  if  they  are  consistent  with  the  CMM  at  level  3. 

•  Information  that  can  be  used  to  develop  software  standards  that  are  consistent 
with  the  CMM  at  level  3. 


The  standards  checklists  contain  only  what  is  recommended  by  the  CMM,  and  are 
not  complete  standards  in  themselves.  For  example,  the  standard  for  the  software 
development  plan  (SDP)  contains  only  content  recommended  by  the  CMM.  Other 
sources  for  the  content  of  a  SDP  should  also  be  considered,  such  as  ANSI/IEEE  Std 
1058.1-1987,  DOD-STD-2167,  DI-MCCR-80030,  etc. 


Continued  on  next  page 
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L3-Standards-1 


0V6rvi©W:  continued 


In  this  section 


This  section  covers  the  following  standards; 


Standard 

KPA 

See  Page 

Action  plan 

OPF 

L3-Standards-3 

Software  development  and  improvement  plan 

OPF 

L3-Standards-4 

Organization’s  standard  software  process 

OPD 

L3-Standards-5 

Software  process  element 

OPD 

L3-Standards-6 

Tailoring  guidelines  and  criteria 

OPD 

L3-Standards-7 

Software  project’s  training  plan 

TP 

L3-Standards-8 

Organization’s  training  plan 

TP 

L3-Standards-9 

Organizational  standards  for  training  courses 

TP 

L3-Standards-10 

Project’s  defined  software  process 

ISM 

L3-Standards-1 1 

Software  design  documentation 

SPE 

L3-Standards-12 

Test  plan 

SPE 

L3-Standards-I3 

Plan  for  intergroup  commitments 

IC 

L3-Standards-14 

Plans  for  peer  reviews 

PR 

L3-Standards-15 

L3-Standards-2 
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Action  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  an  action  plan: 


Recommended  Content 

Which  assessment  findings  will  be  addressed.  (L3-6,  Al) 

Guidelines  for  implementing  the  changes  to  address  findings.  (L3-6,  Al) 

The  groups  or  individuals  responsible  for  implementing  the  changes.  (L3- 
6,  Al) 
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L3-Standards-3 


Software  Process  Development  and  Improvement  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  plan  for  software  process  development  and  improvement.  This  plan: 


V 

Recommended  Content 

Uses  the  action  plans  from  the  software  process  assessments  and  other 
organization  improvement  initiatives  as  primary  inputs.  (L3-7,  A2,  1) 

Defines  the  activities  to  be  performed  and  the  schedule  for  these  activities. 
(L3-7,  A2,  2) 

Specifies  the  groups  and  individuals  responsible  for  the  (software  process 
development  and  improvement)  activities.  (L3-7,  A2,  3) 

_ I 

Identifies  the  resources  required,  including  staff  and  tools.  (L3-7,  A2,  4) 

L3-Standards-4 
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Organization’s  Standard  Software  Process 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  an  organization’s  standard  software  process: 


Recommended  Content 

The  process  is  decomposed  into  constituent  process  elements  to  the 
granularity  needed  to  understand  and  describe  the  process.  (L3-17,  A2,  1) 

Each  process  element  is  described.  (L3-17,  A2,  2) 

[Refer  to  Level  3  Standards  for  additional  information  regarding  software 
process  elements.] 

The  relationships  of  the  process  elements  are  described  and  address  (L3-18, 
A2,  3): 

□  the  ordering, 

□  the  interfaces,  and 

□  the  interdependencies. 

CMU/SEI>94'HB-1 


L3-Standards-5 


Software  Process  Element 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  software  process  element: 


V 

Recommended  Content 

The  required  procedures,  practices,  methods,  and  technologies.  (L3-17,  A2, 
2.1) 

The  applicable  process  and  product  standards.  (L3-17,  A2,  2.2) 

The  responsibilities  for  implementing  the  process.  (L3-18,  A2,  2.3) 

The  required  tools  and  resources.  (L3-18,  A2,  2.4) 

Inputs.  (L3-18,  A2,  2.5) 

The  software  work  products  produced.  (L3-18,  A2,  2.6) 

The  software  work  products  that  should  undergo  peer  review.  (L3-18,  A2, 
2.7) 

The  readiness  and  completion  criteria.  (L3-18,  A2,  2.8) 

The  product  and  process  data  to  be  collected.  (L3-18,  A2,  2.9) 

L3-Standards-6 
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Tailoring  Guidelines  and  Criteria 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  tailoring  guidelines  and  criteria  (for  tailoring  the  organization's  standard 
software  process).  These  guidelines  and  criteria  cover: 


Recommended  Content 

Selecting  and  tailoring  the  software  life  cycle  for  the  project.  (L3-19,  A4, 

1-1) 

Tailoring  the  organization's  standard  software  process  to  accommodate  the 
software  life  cycle  and  the  project's  characteristics.,  (L3-19,  A4,  1.2) 

Standards  for  documenting  the  project's  defined  software  process.  (L3-20, 
A4.  1.3) 
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L3-Standards-7 


Software  Project’s  Ttasning  Plan 


Standard 

checklist 


The  following  table  contains  what  the  Ci  IM  describes  as  the  recommended  content 
of  a  software  project’s  training  plan; 


T 

Recommended  Content 

The  set  of  skills  needed  and  when  those  skills  are  needed.  (L3-29,  Al,  1) 

The  skills  for  which  training  is  required  and  the  skills  that  will  be  obtained 
via  other  vehicles.  (L3-29,  Al,2) 

The  training  that  is  required,  for  whom  it  is  required,  and  when  it  is 
required.  (L3-29,  Al,  3) 

_ 

How  training  will  be  provided.  (L3-30,  Al,  4) 

L3-Standards-8 
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Organization's  Training  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  organization's  training  plan: 


II 

Recommended  Content 

1 

The  specific  training  needed  within  the  organization  and  when  it  is  needed. 
(L3-32,  A3,  1) 

1 

The  training  that  will  be  obtained  from  external  sources  and  training  that 
will  be  provided  by  the  training  group.  (L3-32,  A3,  2) 

1 

The  funding  and  resources  (including  staff,  tools,  and  facilities)  needed  to 
prepare  and  conduct  or  procure  the  training.  (L3-32,  A3,  3) 

Standards  for  instructional  materials  used  in  training  courses  developed  by 
the  training  group.  (L3-32,  A3,  4) 

The  schedule  for  developing  and  revising  the  training  courses  that  will  be 
developed  by  the  training  group.  (L3-32,  A3,  5) 

The  schedule  for  conducting  the  training,  based  on  the  projected  need  dates 
and  the  projected  number  of  students.  (L3-32,  A3,  6) 

The  procedures  for:  (L3-33,  A3,  7) 

□  selecting  the  individuals  who  will  receive  the  training, 

□  registering  and  participating  in  the  training, 

□  maintaining  records  of  the  training  provided,  and 

□  collecting,  reviewing,  and  using  training  evaluations  and  other  training 
feedback. 

CMU/GEI-94-HB-1 


L3-Standards-9 


Organizational  Standards  for  Training  Courses 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  organizational  standards  for  training  courses.  These  standards  requires  that: 


V 

Recommended  Content 

A  description  of  each  training  course  is  developed.  (L3-33,  A4,  1) 

The  materials  for  the  training  course  are  reviewed.  (L3-33,  A4,  2) 

The  materials  for  the  training  courses  are  managed  and  controlled.  (L3-33, 
A4,  3) 

L3-Standards*10 
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Project's  Defined  Software  Process 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  project's  defined  software  process: 


V 

Recommended  Content 

Provisions  are  made  for  gathering,  analyzing,  and  reporting  measurement 
data  needed  to  manage  the  software  project.  (L3-44,  A4,  1 ) 

The  activities  for  software  estimating,  planning,  and  tracking  are  tied  to  the 
key  tasks  and  work  products  of  the  project's  defined  software  process.  (L3- 
44,  A4,  2) 

Readiness  and  completion  criteria  are  established,  documented,  and  used  to 
authorize  initiation  and  determine  completion  of  key  tasks.  (L3-44,  A4,  3) 

Documented  criteria  are  defined  to  indicate  when  to  replan  the  software 
project.  (L3-45,  A4,  4) 

Technical  and  management  lessons  learned  are  documented  and  stored  in 
the  organization's  library  of  software  process-related  documentation.  (L3- 
45,  A4,  5) 

Technical  and  management  lessons  learned  from  monitoring  the  activities  of 
other  projects  in  the  organization  are  systematically  reviewed  and  used  to 
estimate,  plan,  track,  and  replan  the  software  project.  (L3-45,  A4,  6) 

The  staffing  plan  addres.ses  the  software  project's  needs  for  individuals  with 
special  skills  and  application  domain  knowledge.  (L3-45,  A4  7) 

Training  needs  are  identified  and  documented  to  fit  the  specific  needs  of  the 
software  project.  (L3-45,  A4,  8) 

The  software  plans  and  processes  followed  in  interacting  with  other  groups 
are  adjusted  to  account  for  disparities  with  these  groups  and  for  other 
potential  problems.  (L3-45,  A4,  9) 
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Software  Design  Documentation 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  software  design  documentation: 


V 

Recommended  Content 

The  software  components.  (L3-71,  A3,  8.1) 

The  internal  interfaces  between  software  components.  (L3-71,  A3,  8.1) 

The  software  interfaces  to  other  software  systems,  to  hardware,  and  to 
other  system  components  (e.g.,  humans).  (L3-71,  A3,  8.1) 

L3-Standards-12 
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Test  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  test  plan  (for  system  and  acceptance  testing): 


V 

Recommended  Content 

The  overall  testing  and  verification  approach.  (L3-75,  A7,  2.1) 

Responsibilities  of  the  de\^eloping  organization,  subcontractors,  customer, 
and  end  users,  as  appropriate.  (L3-76,  A7,  2.2) 

Test  facility,  test  equipment,  and  test  support  requirements.  (L3-76,  A7, 
2.3) 

_J 

Acceptance  criteria.  (L3-76,  A7, 2.4) 
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Plan  for  intergroup  Commitments 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  plan  for  intergroup  commitments.  This  plan  is: 


V 

Recommended  Content 

The  baseline  for;  (L3-88,  A3,  1) 

□  the  project  schedule, 

□  the  contractual  and  technical  aspects  of  the  project,  and 

□  the  assignment  of  responsibilities  to  the  engineering  groups. 

Updated  to  incorporate  all  intergroup  commitments  and  changes  to  these 
commitments.  (L3-88,  A3,  4) 

Updated  as  the  work  progresses  to  reflect  progress  and  plan  changes  at  the 
project  level,  particularly  when  major  project  milestones  are  completed  and 
when  plans  change  significantly.  (L3-88,  A3,  5) 

L3-Standards-14 
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Plans  for  Peer  Reviews 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  plans  for  peer  reviews.  These  plans; 


Recommended  Content 

Identify  the  software  work  products  that  will  undergo  peer  review.  (L3-97, 
Al,  1) 

□  The  software  work  products  selected  include  the  set  identified  in  the 
organization's  standard  software  process.  fL3-97,  Al.  1.1) 

Specify  the  schedule  of  peer  reviews.  (L3-97,  Al,  2) 

CMU/SEI-94-HB-1 


L3-Standards*15 


Level  3  Process  Checklists 
Overview 


Section  purpose 


In  this  section 


The  purpose  of  the  process  checklists  is  to  provide: 

•  Guidance  in  identifying  which  processes  are  required  by  the  CMM  at  level  3. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  processes  to 
determine  if  they  are  consistent  with  the  CMM  at  level  3. 

•  Information  that  can  be  used  to  develop  software  processes  that  are  consistent 
with  the  CMM  at  level  3. 


This  section  contains  checklists  for  the  following  key  process  areas: 


Key  Process  Area 

See  Page 

Organization  Process  Focus 

L3-Process-3 

Organization  Process  Definition 

L3-Process-25 

Training  Program 

L3-Process-49 

Integrated  Software  Management 

L3-Process-67 

Software  Product  Engineering 

L3-Process-103 

Intergroup  Coordination 

L3-Process-149 

Peer  Reviews 

L3-Process-179 
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Organization  Process  Focus  (OPF)  Process 
OPF  Process  -  Overview 


OPF  process 
purpose 


OPF  process 
description 


The  purpose  of  Organization  Process  Focus  is  to  establish  the  organizational 
responsibility  for  software  process  activities  that  improve  the  organization's  overall 
software  process  capability.  (L3-1) 


Organization  Process  Focus  involves  developing  and  maintaining  an  understanding 
of  the  organization's  and  projects'  software  processes  and  coordinating  the  activities 
tc  assess,  develop,  maintain,  and  improve  these  processes. 

The  organization  provides  the  long-term  commitments  and  resources  to  coordinate 
the  development  and  maintenance  of  the  software  processes  across  current  and 
future  software  projects  via  a  group  such  as  a  software  engineering  process  group. 
This  group  is  responsible  for  the  organization's  software  process  activities.  It  is 
specifically  responsible  for  the  development  and  maintenance  of  the  organization's 
standard  software  process  and  related  process  assets  (as  described  in  the 
Organization  Process  Definition  key  process  area),  and  it  coordinates  the  process 
activities  with  the  software  projects.  (L3-1) 


Continued  on  next  page 
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OPF  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-5 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-9 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-10 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-l  1 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-13 

Exit  Criteria 

Description  of  when  the  process  is 

L3-Process-15 

Reviews  and  i  List  of  teviev  and  audits. 

Audits 

L3-Process-19 

Work  Products 
Managed  and 
Controlled 

ct'.t  of  work  products  to  be  managed  and 
controlled. 

L3-Process-20 

Measurements 

Description  of  process  measurements. 

L3-Process-21 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-22 

Training 

List  of  training. 

L3-Process-23 

Tools 

List  of  tools. 

L3-Process-24 

L3-Process-4 
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OPF  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  focus  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

A  summary  report  from  each  (senior 
management  review  of  the  activities  for 
software  process  development  and 
improvement)  is  prepared  and  distributed 
to  the  affected  groups  and  individuals. 
(L3-10,  VI,  4) 

Group 

responsible  for 
the  organiza¬ 
tion’s  software 
process 
activities 

□  Where  possible,  (the  group  responsible 
for  the  organization’s  software 
process  activities)  is  staffed  by  a  core 
of  software  technical  professionals  who 
are  assigned  full  time  to  the  group, 
possibly  supported  by  others,  on  a  part- 
time  basis.  (L3-4,  Abl,  1) 

□  The  (group  responsible  for  the 
organization’s  software  process 
activities)  is  staffed  to  represent  the 
software  engineering  discipline  and 
software-related  disciplines.  (L3-4, 

Abl,  2) 

□  Members  of  the  group  responsible  for 
the  organization’s  software  process 
activities  receive  required  training  to 
perform  these  activities.  (L3-5,  Ab3) 

□  Where  appropriate,  training  (for  the 
organization’s  and  projects’  software 
processes)  may  be  prepared  and 
conducted  by  the  group  responsible 
for  the  organization’s  software 
process  activities  (e.g.,  software 
engineering  process  group)  or  by  the 
training  group.  (L3-8,  A6,  2) 

Groups 
involved  in 
implementing 
the  software 
processes 

The  groups  involved  in  implementing  the 
software  processes  are  informed  of  the 
organization’s  and  projects’  activities  for 
software  process  development  and 
improvement.  (L3-9,  A7) 

Continued  on  next  page 


CMU/SEi-94-HB-1 


L3-Process-5 


OPF  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  focus  process,  continued  from  the  previous  page 


V 

Role 

Activities  Participated  in... 

Reference 

Individuals 

□  Experienced  individuals  who  have 
expertise  in  specialized  areas  are 
committed  to  support  (the  group 
responsible  for  the  organization’s 
software  process  activities).  (L3-5, 

Ab2,  1) 

□  A  summary  report  from  each  (senior 
management)  review  (of  the  activities 
for  software  process  development  and 
improvement)  is  prepared  and 
distributed  to  the  affected  groups  and 
individuals.  (L3-10,  Vl,4) 

Managers 

□  Senior  management  coordinates 
software  process  requirements  and 
issues  with  higher  level  staff  and 
managers.  (L3-3,  C3,  3.1) 

□  Senior  management  coordinates  with 
the  organization’s  managers  to  secure 
the  managers’  and  staffs  support  and 
participation.  (L3-3,  C3,  3.2) 

i 

I 

Senior 

management 

□  Senior  management  sponsors  the 

organization’s  activities  for  software 

process  development  and  improvement. 

(L3-2.  C2) 

Senior  management; 

□  Demonstrates  to  the  organization’s 
staff  and  managers  its  commitment 
to  these  software  process  activities. 

□  Establishes  long-term  plans  and 
commitments  for  funding,  staffing, 
and  other  resources. 

□  Establishes  strategies  for  managing 
and  implementing  the  activities  for 
process  development  and 
improvement. 

Role  continues  on  the  next  page 

Continued  on  next  page 
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OPF  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organi/^ation  process  focus  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Senior 

management, 

continued 

□  Senior  management  oversees  the 
organization’s  activities  for  software 
process  development  and  improvement. 
(L3-3,  C3) 

Senior  management: 

□  Ensures  that  the  organization’s 
standard  software  process  supports 
its  business  goals  and  strategies. 

□  Advises  on  setting  priorities  for 
software  process  development  and 
improvement. 

□  Participates  in  establishing  plans  for 
software  process  development  and 
improvement. 

□  Coordinates  software  process 
requirements  and  issues  with 
higher  level  staff  and  managers. 

□  Coordinates  with  the 
organization’s  managers  to 
secure  the  managers’  and 
staff’s  support  and 
participation. 

□  The  activities  for  software  process 
development  and  improvement  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3-10,  ’VI) 

Senior 

managers 

(The  organizational  plan  for  software 
process  development  and  improvement 
activities)  is  reviewed  and  agreed  to  by  the 
organization’s  software  managers  and 
senior  managers.  (L3-7,  A2,  6) 

Software 

engineering 

group 

Members  of  the  .software  engineering 
group  and  other  software-related  groups 
receive  orientation  on  the  organization’s 
software  process  activities  and  their  roles  in 
those  activities.  (L3-6,  Ab4) 

Continued  on  next  page 
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OPF  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  focus  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 

managers 

(The  organizational  plan  for  software 
process  development  and  improvement 
activities)  is  reviewed  and  agreed  to  by  the 
organization’s  software  managers  and 
senior  managers.  (L3-7,  A2,  6) 

Software- 
related  groups 

Members  of  the  software  engineering 
group  and  other  software-related  groups 
receive  orientation  on  the  organization’s 
software  process  activities  and  their  roles  in 
those  activities.  (L3-6,  Ab4) 

Staff 

Senior  management  coordinates  software 
process  requirements  and  issues  with  higher 
level  staff  and  managers.  (L3-3,  C3,  3.1 ) 

Training 

group 

Where  appropriate,  training  for  the 
organization’s  and  projects’  software 
processes  may  be  prepared  and  conducted 
by  the  group  responsible  for  the 
organization’s  software  process  activities 
(e.g.,  software  engineering  process  group) 
or  by  the  training  group.  (L3-8,  A6,  2) 

L3-Process-8 
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OPF  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  for  the  organization  process  focus  process. 


The  CMM  recommends  that  the  conditions  described  i:.  the  table  below  be  satisfied 
before  entering  the  organization  process  focus  process. 


Condition 

References 

The  organization  follows  a  written  organizational  policy  for 
coordinating  software  process  development  and 
improvement  activities  across  the  organization.  (L3-2,  C!) 

[Refer  to  Level  3  Policies  for  additional  information 
regarding  OPF  policy.] 

Senior  management  sponsors  the  organization’s  activities 
for  software  process  development  and  improvement.  (L3-2, 
C2) 

Senior  management  oversees  the  organization’s  activities 
for  software  process  development  and  improvement.  (L3-3, 
C3) 

A  group  that  is  responsible  for  the  organization’s  software 
process  activities  exists.  (L3-3,  Abl ) 

Where  possible,  the  group  responsible  for  the 
organization’s  software  process  activities  is  staffed  by  a 
coie  of  software  technical  professionals  who  are  assigned 
full  time  to  the  group,  possibly  supported  by  others,  on  a 
part-time  basis.  (L3-4,  Abl,  1) 

The  group  responsible  for  the  organization’s  software 
process  activities  is  staffed  to  represent  the  software 
engineering  discipline  and  software-related  disciplines.  (L3- 
4.  Abl,  2) 

Adequate  resources  and  funding  are  provided  for  the 
organization’s  software  process  activities.  (L3-4,  Ab2) 

Experienced  individuals  who  have  expertise  in  specialized 
areas  are  committed  to  support  the  group  responsible  for 
the  organization’s  software  process  activities.  (L3-5,  Ab2, 

1) 

Tools  to  support  the  organization’s  software  process 
activities  are  made  available.  (L3-5,  Ab2,  2) 

Members  of  the  group  responsible  for  the  organization’s 
software  process  activities  receive  required  training  to 
perform  these  activities.  (L3-5,  Ab3) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  receive  orientation  on  the 
organization’s  software  process  activities  and  their  roles  in 
those  activities.  (L3-6,  Ab4) 
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OPF  Process  -  Inputs 


Inputs 


The  table  below  lists  the  inputs  to  the  organization  process  focus  process. 


T 

Input 

Org.  Input 

References 

Action  plans  from  the  software  process 
assessments.  (L3-7,  A2,  1) 

Business  goals  and  strategies.  (L3-3,  C3,  1) 

Improvements  to,  and  other  useful 
information  on,  each  project’s  software 
process,  tools,  and  methods.  (L3-2,  Cl,  4) 

New  processes,  methods,  and  tools  in 
limited  use  in  the  organization.  (L3-8,  A5) 

Organization  improvement  initiatives.  (L3- 
7,  A2,  1) 

Organization’s  software  process  database. 
(L3-8,  A4) 

Organization’s  standard  software  process. 
(L3-2,  Cl,  3) 

Plan  for  the  organization’s  soft'»'are 
process  development  and  improvement 
activities.  (L3-7,  A2) 

Progress  and  status  of  the  activities  to 
develop  and  improve  the  software  process. 
(L3-10,  VI,  1) 

Projects’  defined  software  process.  (L3-8, 
A3,  2) 

Software  process  issues.  (L3-3,  C3,  3.1) 

Software  process  requirements.  (L3-3,  C3, 
3.1) 

Software  process.  (L3-6,  Al) 

Software  processes  used  by  the  project. 
(L3-2,  Cl,  2) 
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OPF  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  organization  process  focus 
process. 


V 

Activities 

References 

The  software  process  is  assessed  periodically,  and  action 
plans  are  developed  to  address  the  assessment  findings.  (L3- 
6,A1) 

The  organization  develops  and  maintains  a  plan  for  its 
software  process  development  and  improvement  activities. 
(L3-7,  A2) 

The  organization’s  and  projects’  activities  for  developing 
and  improving  their  software  processes  are  coordinated  at 
the  organization  level.  (L3-7,  A3) 

This  coordination  covers  the  development  and  improvement 
of: 

□  The  organization’s  standard  software  process. 

□  The  projects'  defined  software  processes. 

The  use  of  the  organization’s  software  process  database  is 
coordinated  at  the  organizational  level.  (L3-8,  A4) 

New  processes,  methods,  and  tools  in  limited  use  in  the 
organization  are  monitored,  evaluated,  and,  '.here 
appropriate,  transferred  to  other  parts  of  the  organization. 
(L3-8,  A5) 

Training  for  the  organization’s  and  projects’  software 
processes  is  coordinated  across  the  organization.  (L3-8,  A6) 

□  Plans  for  training  on  subjects  related  to  the 
organization’s  and  projects’  .software  processes  are 
prepared. 

□  Where  appropriate,  training  may  be  prepared  and 
conducted  by  the  group  responsible  for  the 
organization’s  software  process  activities  (e.g.,  software 
engineering  process  group)  or  by  the  training  group. 

The  groups  involved  in  implementing  the  software 
processes  are  informed  of  the  organization’s  and  projects’ 
activities  for  software  process  development  and 
improvement.  (L3-9,  A7) 

Continued  on  next  page 
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OPF  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  organization  process  focus 
process,  continued  from  the  previous  page. 


V 

Activities 

References 

Measurements  are  made  and  used  to  determine  the  status  of 
the  organization’s  process  development  and  improvement 
activities.  (L3-9,  MI) 

The  activities  for  software  process  development  and 
improvement  are  reviewed  with  senior  management  on  a 
periodic  basis.  (L3-10,  VI) 

□  Progress  and  status  of  the  activities  to  develop  and 
improve  the  software  process  are  reviewed  against  the 
plan. 

□  Conflicts  and  issues  not  resolved  at  lower  levels  are 
addressed. 

□  Action  items  are  assigned,  reviewed,  and  tracked  to 
closure. 

□  A  summary  report  from  each  review  is  prepared  and 
distributed  to  the  affected  groups  and  individuals. 
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OPF  Process  -  Outputs 


Outputs 


The  table  below  lists  the  outputs  produced  by  the  organization  process  focus 
process. 


Output 

Org.  Outputs 

References 

Action  items  (from  senior  management 
reviews  of  the  activities  for  software  process 
development  and  improvement).  (L3-10, 
VI,  3) 

Action  plans.  (L3-6,  AI) 

Assessment  findings.  (L3-6,  Al) 

Conflicts  and  issues  not  resolved  at  lower 
levels.  (L3-10,  VI,2) 

Improvements  to,  and  other  useful 
information  on,  each  project’s  software 
process,  tools,  and  methods.  (L3-2,  Cl,  4) 

Long-term  plans  and  commitments  for 
funding,  staffing,  and  other  resources  (for 
the  organization’s  activities  for  software 
process  development  and  improvement). 
(L3-3,  C2,  2) 

Measurements  (to  determine  the  status  of 
the  organization’s  process  development 
and  improvement  activities).  (L3-9,  Ml) 

Plan  for  organizational  software  process 
development  and  improvement  activities. 
(L3-7,  A2) 

Plans  for  software  process  development 
and  improvement.  (L3-3,  C3,  3) 

Plans  for  training  on  subjects  related  to  the 
organization’s  and  projects’  .software 
processes.  (L3-8,  A6,  1) 

Priorities  for  software  process  development 
and  improvement.  (L3-3,  C3,  2) 

Progress  and  status  of  the  activities  to 
develop  and  improve  the  software  process. 
(L3-10,  VI,  1) 

Schedule  for  the  software  process 
development  and  improvement  activities. 
(L3-7,  A2,  2) 

Software  process  issues.  (L3-3,  C3,  3.1) 

Software  process  requirements.  (L3-3,  C3, 
3.1) 

Continued  on  next  page 
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OPF  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  organization  process  focus 
process,  continued  from  the  previous  page. 


Output 

Org.  Outputs 

References 

Strategies  for  managing  and  implementing 
the  activities  for  process  development  and 
improvement.  (L3-3,  C2,  3) 

Summary  report  from  each  (senior 
management)  review  of  the  activities  for 
software  process  development  and 
improvement.  (L3-10,  Vl,4) 
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OPF  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  focus  process. 


V 

Output 

State 

References 

Action  items  (from 
senior  management 
reviews  of  the 
activities  for  software 
process  development 
and  improvement) 

□  are  assigned.  (L3-10,  VI,  3) 

□  are  reviewed.  (L3-10,  VI,  3) 

□  are  tracked  to  closure.  (L3-10, 
VI,  3) 

Action  plans 

are  developed  to  address  software 
process  assessment  findings.  (L3-6, 
AI) 

Conflicts  and  issues 
not  resolved  at  lower 
levels 

are  addressed  (during  senior 
management  reviews  of  the  activities 
for  software  process  development 
and  improvement).  (L3-10,  VI,  2) 

Improvements  to,  and 
other  useful 
information  on,  each 
project’s  software 
process,  tools,  and 
methods 

are  available  to  other  projects.  (L3- 
2.  Cl,  4) 

Long-term  plans  and 
commitments  for 
funding,  staffing,  and 
other  resources  (for 
the  organization’s 
activities  for  software 
process  development 
and  improvement) 

are  establish -“d  by  senior 
management.  (L3-3,  C2,  2) 

Measurements  (to 
determine  the  status 
of  the  organization’s 
process  development 
and  improvement 
activities) 

□  are  made.  (L3-9,  Ml) 

□  are  used.  (L3-9,  Ml) 

Continued  on  next  page 
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OPF  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  focus  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Plan  for 
organizational 
software  process 
development  and 
improvement 
activities 

□  is  developed  by  the  organization. 
(L3-7,  A2) 

□  is  maintained  by  the 
organization.  (L3-7,  A2) 

□  undergoes  peer  review  when 
initially  released  and  whenever 
major  revisions  are  made.  (L3-7, 
A2,  5) 

□  is  reviewed  and  agreed  to  by  the 
organization’s  software 
managers  and  senior  managers. 
(L3-7,  A2,  6) 

Plans  for  software 
process  development 
and  improvement 

are  established  with  the  participation 
of  senior  management.  (L3-3,  C3, 

3) 

Plans  for  training  on 
subjects  related  to  the 
organization’s  and 
projects’  software 
processes 

are  prepared.  (L3-8,  A6,  1) 

Priorities  for  software 
process  development 
and  improvement 

are  set  with  the  advice  of  senior 
management.  (L3-3,  C3,  2) 

Progress  and  status  of 
the  activities  to 
develop  and  improve 
the  software  process 

are  reviewed  against  the  plan.  (L3- 
10,  VI,  1) 

Schedule  for  the 
software  process 
development  and 
improvement 
activities 

is  defined  in  the  plan  (for 
organizational  software  process 
development  and  improvement 
activities).  (L3-7,  A2,  2) 

Software  process 
issues 

are  coordinated  by  senior 
management  with  higher  level  staff 
and  managers.  (L3-3,  C3,  3.1) 

Software  process 
requirements 

are  coordinated  by  senior 
management  with  higher  level  staff 
and  managers.  (L3-3,  C3,  3.1) 

Continued  on  next  page 
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OPF  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  focus  process,  continued  from  the  previous  page. 


< 

Output 

State 

References 

Strategies  for 
managing  and 
implementing  the 
activities  for  process 
development  and 
improvement 

are  established  by  senior 
management.  (L3-3,  C2,  3) 

Summary  report 
from  each  (senior 
management)  review 
of  the  activities  for 
software  process 
development  and 
improvement 

□  is  prepared.  (L3-10,  VI,  4) 

□  is  distributed  to  the  affected 
groups  and  individuals.  (L3'10, 
VI,  4) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  organization  process  focus  process. 


V 

Condition 

References 

The  software  processes  used  by  the  projects  are  assessed 
periodically  to  determine  their  strengths  and  weaknesses. 
(L3-2,  Cl,2) 

The  software  processes  used  by  the  projects  are 
appropriately  tailored  from  the  organization's  standard 
software  process.  (L3-2,  Cl,3) 

The  organization’s  standard  software  process  supports  its 
business  goals  and  strategies.  (L3-3,  C3,  1) 

The  software  process  is  assessed  periodically,  and  action 
plans  are  developed  to  address  the  assessment  findings.  (L3- 
6,A1) 

The  organization’s  and  projects’  activities  for  developing 
and  improving  their  software  processes  are  coordinated  at 
the  organization  level.  (L3-7,  A3) 

This  coordination  covers  the  development  and  improvement 
of: 

□  The  organization’s  standard  software  process. 

□  The  projects’  defined  software  processes. 

The  use  of  the  organization’s  software  process  database  is 
coordinated  at  the  organizational  level.  (L3-8,  A4) 

Continued  on  next  page 
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OPF  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  org  .nization  process  focus  process,  continued  from  the  previous  page. 


V 

Condition 

References 

New  processes,  methods,  and  tools  in  limited  use  in  the 
organization  are  monitored,  evaluated,  and,  where 
appropriate,  transferred  to  other  parts  of  the  organization. 
(L3-8,  A5) 

Training  for  the  organization’s  and  projects’  software 
processes  is  coordinated  across  the  organization.  (L3-8,  A6) 

The  groups  involved  in  implementing  the  software 
processes  are  informed  of  the  organization’s  and  projects’ 
activities  for  software  process  development  and 
improvement.  (L3-9,  A7) 

The  activities  for  software  process  development  and 
improvement  are  reviewed  with  senior  management  on  a 
periodic  basis.  (L3-10,  VI) 
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OPF  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  organization 
process  focus  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  plan  for  organizational  software 
process  development  and  improvement 
activities  undergoes  peer  review  when 
initially  released  md  \/henever  major 
revisions  are  maao,  •  'Ji-1,  A2,  5) 

Not  specifled  in 
the  CMM 

The  plan  for  organizational  software 
process  development  and  improvement 
activities  is  reviewed  and  agreed  to  by  the 
organization's  software  managers  and 
senior  managers.  (L3-7,  A2,  6) 

Software 

managers 

Senior 

managers 

The  activities  for  software  process 
development  and  improvement  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3-I0,  VI) 

Senior 

management 

Progress  and  status  of  the  activities  to 
develop  and  improve  the  software  process 
are  reviewed  against  the  plan.  (L3-10,  VI, 

1) 

Not  specified  in 
the  CMM 
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OPF  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


There  are  no  work  products  that  are  recommended  to  be  managed  and  controlled 
during  the  organization  process  focus  process. 
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OPF  Process  -  Measurements 


Measurements 


The  table  below  lists  the  recommended  measurements  for  the  organization  process 
focus  process. 


V 

Measurements 

References 

Measurements  to  determine  the  status  of  the  organization’s 
process  development  and  improvement  activities.  (L3-9, 

Ml) 

Examples  of  measurements  include: 

□  Work  completed,  effort  expended,  and  funds  expended 
in  the  organization’s  activities  for  process  assessment, 
development,  and  improvement  compared  to  the  plans 
for  these  activities. 

□  Results  of  each  software  process  assessment,  compared  to 
the  results  and  recommendations  of  previous 
assessments. 
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OPF  Process  -  Documented  Procedures 


Documented 

procedures 


There  are  no  activities  that  are  recomm‘’:ided  to  be  performed  according  to  a 
documented  procedure  in  the  organization  process  focus  process. 
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OPF  Process  -  Training 


Training 


The  table  belov/  lists  the  training  recommended  for  the  organization  process  focus 
process. 


V 

Training 

References 

Members  of  the  group  responsible  for  the  organization’s 
software  process  activities  receive  required  training  to 
perform  these  activities.  (L3-5,  Ab3) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  receive  orientation  on  the 
organization’s  software  process  activities  and  their  roles  in 
those  activities.  (L3-6,  Ab4) 

Training  for  the  organization’s  and  projects’  software 
processes.  (L3-8,  A6) 

□  Where  appropriate,  training  may  be  prepared  and 
conducted  by  the  group  responsible  for  the 
organization's  software  process  activities  (e.g., 
software  engineering  process  group)  or  by  the  training 
group.  (L3-8,  A6,  2) 
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OPF  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  organization  process  focus 
process. 


T 

Tools 

References 

Tools  to  support  the  organization’s  software  process 
activities.  (L3-5,  Ab2,  2) 

Examples  of  support  tools  include; 

□  statistical  analysis  tools, 

□  desktop  publishing  tools, 

□  database  management  systems,  and 

□  process  modeling  tools. 
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Organization  Process  Definition  (OPD)  Process 
OPD  Process  -  Overview 


OPD  process 
purpose 


OPD  process 
description 


The  purpose  of  Organization  Process  Definition  is  to  develop  and  maintain  a 
usable  set  of  software  process  assets  that  improve  process  performance  across  the 
projects  and  provide  a  basis  for  cumulative,  long-term  benefits  to  the  organization. 
(L3-11) 


Organization  Process  Definition  involves  developing  and  maintaining  the 
organization's  standard  software  process,  along  with  ••elated  process  assets,  such  as 
descriptioi  of  software  life  cycles,  process  tailoring  guidelines  and  criteria,  the 
organization’s  software  process  database,  and  a  library  of  software  process-related 
documentation. 

These  assets  may  be  collected  in  many  ways,  depending  on  the  organization's 
implementation  of  Organization  Process  Definition.  For  example,  the  descriptions 
of  the  software  life  cycles  may  be  an  integral  part  of  the  organization's  standard 
software  process  or  parts  of  the  library  of  software  process-related  documentation 
may  be  stored  in  the  organization's  software  process  database. 

The  organization's  software  process  assets  are  available  for  use  in  developing, 
implementing,  and  maintaining  the  projects'  defined  software  processes.  (The 
practices  related  to  the  development  and  maintenance  of  the  project's  defined 
software  process  are  described  in  the  Integrated  Software  Management  key  process 
area.)  (L3-11) 


Continued  on  next  page 
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OPD  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-27 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-29 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-30 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-31 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-33 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-35 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L3-Process-41 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-43 

Measurements 

Description  of  process  measurements. 

L3-Process-44 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process*45 

Training 

List  of  training. 

L3-Process-46 

Tools 

List  of  tools. 

L3-Process-47 
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OPD  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate-  in  the 
organization  process  definition  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Group 

responsible  for 
the  organiza¬ 
tion’s  software 
process 
activities  (e.g., 
software 
engineering 
process 
group) 

□  The  development  and  maintenance  of 
the  organization's  standard  software 
process  and  related  process  assets  is 
performed  or  coordinated  by  the 
group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group).  (L3-14,  Abl,  1) 

□  Changes  proposed  for  the 
organization's  standard  software 
process  are  documented,  reviewed,  and 
approved  by  the  group  responsible  for 
the  organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  before  they  are 
incorporated.  (L3-16,  Al,  6) 

□  Changes  proposed  for  the  descriptions 
of  software  life  cycles  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g., 
software  engineering  process  group) 
before  they  are  incorporated.  (L3-18, 
A3,  2) 

□  Changes  proposed  for  the  tailoring 
guidelines  and  criteria  (for  the 
projects’  tailoring  of  the  organization’s 
standard  software  process)  are 
documented,  reviewed,  and  approved 
by  the  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  before  they  are 
incorporated.  (L3-20,  A4,  2) 

Continued  on  next  page 
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OPD  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  definition  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Individuals 
who  develop 
and  maintain 
the 

organization's 
standard 
software 
process  and 
related  process 
assets 

The  individuals  who  develop  and 
maintain  the  organization's  standard 
software  process  and  related  process 
assets  receive  required  training  to  perform 
these  activities.  (L3-14,  Ab2) 

1 _ 

Software 

quality 

assurance 

group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  organization's 
activities  and  work  products  for  develop  ng 
and  maintaining  the  organization's  standard 
software  process  and  related  process  assets 
and  reports  the  results.  (L3-23,  V1 1 
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OPD  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  desciibed  in  the  table  below 
before  entering’  the  organization  process  definition  process. 


Input 

State 

References 

Descriptions  of 
software  life  cycles 

□  are  approved  for  use  by  the 
projects.  (L3-18,  A3) 

□  are  documented.  (L3-18,  A3) 

Organizational 
standards  (for 
documenting  the 
organization’s 
standard  software 
process) 

are  established.  (L3-17,  A2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  organization  process  definition  process. 


Condition 

References 

The  organization  follows  a  written  policy  for  developing  and 
maintaining  a  standard  software  process  and  related  process 
assets.  (L3-12,  Cl) 

[Refer  to  Level  3  Policies  for  additional  information 
regarding  OPD  policy.] 

Adequate  resources  and  funding  are  provided  for 
developing  and  maintaining  the  organization's  standard 
software  process  and  related  process  assets.  (L3-14,  Abl) 

The  development  and  maintenance  of  the  organization's 
standard  software  process  and  related  process  asset.^  is 
performed  or  coordinated  by  the  group  responsible  for  the 
organization's  software  process  activities  (e.g.,  software 
engineering  process  group).  (L3-14,  Abl,  1) 

Tools  to  support  process  development  and  maintenance  are 
made  available.  (L3-14,  Abl,  2) 

The  individuals  who  develop  and  maintain  the 
organization's  standard  software  process  and  related 
process  assets  receive  required  training  to  perform  these 
activities.  (L3-14,  Ab2) 
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OPD  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  organization  process 
definition  process. 


V 

Input 

Org.  Input 

References 

Candidate  documentation  items.  (L3-21, 

A6,  1) 

Changes  proposed  for  the  descriptions  of 
software  life  cycles.  (L3-18,  A3,  2) 

Changes  proposed  for  the  organization's 
standard  software  process.  (L3-16,  Al,  6) 

Changes  proposed  for  the  tailoring 
guidelines  and  criteria.  (L3-20,  A4,  2) 

Data  entered  into  the  (software  process) 
database.  (L3-21 ,  A5,  2) 

Data  on  the  software  work  products 
(resulting  from  the  software  processes). 
(L3-20,  A5,  1) 

Data  on  the  software  processes.  (L3-20, 

A5,  1) 

Descriptions  of  software  life  cycles.  (L3- 
18,  A3) 

Guidelines  and  criteria  for  the  projects’ 
tailoring  of  the  organization’s  standard 
software  process.  (L3-19,  A4) 

Information  collected  from  the  projects  (to 
improve  the  organization’s  standard 
software  process).  (L3-13,  Ci,4) 

Library  of  software  process-related 
documentation.  (L3-21,  A6) 

Organization’s  software  process  assets  or 
related  process  assets.  (L3-12,  Cl) 

Organization’s  standard  software  process. 
(L3-12,  Cl) 

Organization  standards.  (L3-17,  A2) 

Software  policies.  (L3-15,  Al,  1) 

Software  process  standards.  (L3-15,  Al,  1) 

Software  product  standards.  (L3-15,  Al, 

1) 

State-of-the-practice  software  engineering 
methods.  (L3-15,  Al,  3) 

State-of-the-practice  software  engineering 
tools.  (L3-15,  Al,3) 
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OPD  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  organization  process 
definition  process. 


Activities 

References 

The  organization's  standard  software  process  is  developed 
and  maintained  according  to  a  documented  procedure.  (L3- 
15,  Al) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  organization's  standard  software  process  is  documented 
according  to  established  organization  standards.  (L3-17, 

A2) 

[Refer  to  Level  3  Standards  for  additional  information 
regarding  the  organization's  standard  software  process.] 

Descriptions  of  software  life  cycles  that  are  approved  for  use 
by  the  projects  are  documented  and  maintained.  (L3-18, 

A3) 

□  Changes  proposed  for  the  descriptions  of  software  life 
cycles  are  documented,  reviewed,  and  approved  by  the 
group  responsible  for  the  organization's  software 
process  activities  (e.g.,  software  engineering  process 
group)  before  they  are  incorporated.  (L3-18,  A3,  2) 

□  The  descriptions  of  the  software  life  cycles  undergo  peer 
review  when  initially  documented  and  whenever 
significant  changes  or  additions  are  made.  (L3-19,  A3, 

3) 

□  The  descriptions  of  the  software  life  cycles  are  managed 
and  controlled.  (L3-19,  A3,  4) 

Guidelines  and  criteria  for  the  projects'  tailoring  of  the 
organization's  standard  software  process  are  developed  and 
maintained.  (L3-19,  A4) 

□  The  tailoring  guidelines  and  criteria  are  managed  and 
controlled.  (L3-20,  A4,  3) 

[Refer  to  Level  3  Standards  for  additional  information 
regarding  tailoring  guidelines  and  criteria.] 

Continued  on  next  page 
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OPD  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  organization  process 
definition  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  organization's  software  process  database  is  established 

and  maintained.  (L3-20,  A5) 

□  The  database  is  established  to  collect  and  make  available 
data  on  the  software  processes  and  resulting  software 
work  products. 

□  The  data  entered  into  the  database  are  reviewed  to  ensure 
the  integrity  of  the  database  contents. 

□  The  database  is  managed  and  controlled. 

□  User  access  to  the  database  contents  is  controlled  to 
ensure  completeness,  integrity,  and  accuracy  of  the  data. 

A  library  of  software  process-related  documentation  is 

established  and  maintained.  (L3-21,  A6) 

□  Candidate  documentation  items  are  reviewed  and 
appropriate  items  that  may  be  useful  in  the  future  are 
included  in  the  library. 

□  The  documentation  items  are  catalogued  for  easy  access. 

□  Revisions  made  to  documentation  items  currently  in  the 
library  are  reviewed,  and  the  library  contents  are  updated 
as  appropriate. 

□  The  library  contents  are  made  available  for  use  by  the 
software  projects  and  other  software-related  groups. 

□  The  use  of  each  documentation  item  is  reviewed 
periodically,  and  the  results  are  used  to  maintain  the 
library  contents. 

□  The  library  contents  are  managed  and  controlled. 

Measurements  are  made  and  used  to  determine  the  status  of 
the  organization's  process  definition  activities.  (L3-22,  Ml) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  organization's  activities  and  work  products  for 
developing  and  maintaining  the  organization's  standard 
software  process  and  related  process  assets  and  reports  the 
results.  (L3-23,  VI) 
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OPD  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  organization 
process  definition  process. 


V 

Output 

Org.  Output 

References 

Candidate  documentation  items  (for  the 
library  of  software  process-related 
documentation).  (L3-21,  A6,  1) 

Data  on  the  software  work  products 
(resulting  from  the  software  processes). 
(L3-20,  A5,  1) 

Data  on  the  software  processes.  (L3-20, 

A5,  1) 

Descriptions  of  software  life  cycles  or 
software  life  cycles.  (L3-18,  A3) 

External  process  interfaces  between  the 
software  process  and  the  processes  of  other 
affected  groups.  (L3-16,  Al,  5) 

Guidelines  and  criteria  for  the  projects’ 
tailoring  of  the  organization’s  standard 
software  process.  (L3-19,  A4) 

Internal  process  interfaces  between  the 
software  disciplines.  (L3-15,  Al,  4) 

Library  of  software  process-related 
documentation  or  library  contents.  (L3- 
21,  A6) 

Measurements  (to  determine  the  status  of 
the  organization’s  process  definition 
activities).  (L3-22,  Ml) 

Organization’s  software  process  assets  or 
related  process  assets.  (L3- 1 2,  C 1 ) 

Organization’s  standard  software  process. 
(L3-12,  Cl) 

Plans  for  introducing  changes  to  the 
software  process  of  ongoing  projects.  (L3- 
16,  Al,  7) 

Process  element  relationships.  (L3-18,  A2, 
3) 

Process  element.  (L3-17,  A2,  1) 

1 

Results  of  periodic  reviews  of  the  use  of 
software-process  related  documentation 
items.  (L3-22,  A6,  5) 

1  Results  of  SQA  group  reviews  and/or 

1  audits.  (L3-23,  VI) 

Continued  on  next  page 
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OPD  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  organization 
process  definition  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Revisions  made  to  documentation  items 
currently  in  the  (software  process-related 
documentation)  library.  (L3-22,  A6,  3) 

Software  process-related  documentation  or 
documentation  items.  (L3-21,  A6) 
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OPD  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process. 


Output 

State 

References 

Candidate  (software 
process-related) 
documentation  items 

□  are  reviewed.  (L3-21,  A6,  1) 

□  are  included  in  the  library  (of 
software  process-related 
documentation),  if  they  may  be 
useful  in  the  future.  (L3-21,  A6, 
1) 

Data  on  the  software 
work  products 
(resulting  from  the 
software  processes) 

□  are  collected  into  the 
organization's  software  process 
database.  (L3-20,  A5) 

□  are  made  available  from  the 
organization’s  software  process 
database.  (L3-20,  A5) 

□  completeness  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  integrity  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  accuracy  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

Data  on  the  software 
processes 

□  are  collected  into  the 
organization's  software  process 
database.  (L3-20,  A5) 

□  are  made  available  from  the 
organization's  software  process 
database.  (L3-20,  A5) 

□  completeness  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  integrity  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  accuracy  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21 ,  A5,  4) 

Continued  on  next  page 
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OPD  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Descriptions  of 
software  life  cycles 

□  are  documented.  (L3-18,  A3) 

□  are  maintained.  (L3-18,  A3) 

□  are  compatible  with  the 
organization's  standard  software 
process.  (L3-18,  A3,  1) 

□  undergo  peer  review  when 
initially  documented  and 
whenever  significant  changes  or 
additions  are  made.  (L3-19,  A3, 
3) 

□  are  managed  and  controlled. 
(L3-19,  A3,  4) 

External  process 
interfaces  between 
the  software  process 
and  the  processes  of 
other  affected  groups 

are  described.  (L3-16,  Al,  5) 

Guidelines  and 
criteria  for  the 
projects’  tailoring  of 
the  organization’s 
standard  software 
process 

□  are  developed.  (L3-19,  A4) 

□  are  maintained.  (L3-19,  A4) 

□  are  managed  and  controlled. 
(L3-20,  A4,  3) 

Internal  process 
interfaces  between 
the  software 
disciplines 

are  described.  (L3-15,  Al,  4) 

Library  of  software 
process-related 
documentation  or 
library  contents 

□  is  established.  (L3-21,  A6) 

□  is  maintained.  (L3-21,  A6) 

□  is  updated  as  appropriate.  (L3- 
22,  A6,  3) 

□  is  made  available  for  use  by  the 
software  projects  and  other 
software-related  groups.  (L3-22, 
A6,  4) 

□  is  managed  and  controlled.  (L3- 
22,  A6,  6) 

Continued  on  next  page 
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OPD  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Measurements  (to 
determine  the  status 
of  the  organization's 
process  definition 
activities) 

□  are  made.  (L3-22,  Ml) 

□  are  used.  (L3-22,  Ml) 

Organization’s 
software  process 
assets  or  related 
process  assets 

□  are  maintained.  (L3-13,  Cl,  3) 

□  are  controlled.  (L3'23,  VI,  2) 

□  are  used  appropriately.  (L3-23, 
VI,  2) 

Continued  on  next  page 
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OPD  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Organization’s 
standard  software 
process 

□  is  defined  for  the  organization. 
(L3-12,  Cl.  1) 

□  is  developed  according  to  a 
documented  procedure.  (L3-15, 
Al) 

□  is  maintained  according  to  a 
documented  procedure.  (L3-15, 
Al) 

□  satisfies  the  software  policies, 
process  standards,  and  product 
standards  imposed  on  the 
organization,  as  appropriate. 
(L3-15,  Al,  1) 

□  satisfies  the  software  process  and 
product  standards  that  are 
commonly  imposed  on  the 
organization's  projects  by  their 
customers,  as  appropriate.  (L3- 
15,  Al,  2) 

□  incorporates  state-of-the-practice 
software  engineering  tools  and 
methods,  as  appropriate.  (L3-15, 
Al,3) 

□  description  undergoes  peer 
review  when  initially  developed 
and  whenever  significant  changes 
or  additions  are  made.  (L3-16, 
Al,8) 

□  is  placed  under  configuration 
management.  (L3-17,  Al,  9) 

□  is  documented  according  to 
established  organization 
standards.  (L3-17,  A2) 

□  is  decomposed  into  constituent 
process  elements  to  the 
granularity  needed  to  understand 
and  describe  the  process.  (L3- 
17,  A2,  1) 

Exit  criteria  continued  on  next  page 
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OPD  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


~T 

Output 

State 

References 

Organization’s 
standard  software 
process,  continued 

□  is  controlled.  (L3-23,  VI,  2) 

□  is  used  appropriately.  (L3-23, 

VI,  2) 

Plans  for  introducing 
changes  to  the 
software  process  of 
ongoing  projects 

are  defined  as  appropriate.  (L3-16, 
Al,7) 

Process  element 
relationships 

□  are  described.  (L3-18,  A2,  3) 

□  address:  (L3-18,  A2,  3) 

□  the  ordering, 

□  the  interfaces,  and 

□  the  interdependencies. 

Process  element 

is  described.  (L3-17,  A2,  2) 

.. 

Results  of  periodic 
reviews  of  the  use  of 
documentation  items 

are  used  to  maintain  the  library  (of 
software  process-related 
documentation)  contents.  (L3-22, 

A6,  5) 

Results  of  SQA 
group  reviews  and/or 
audits 

are  reported.  fL3-23,  VI) 

Revisions  made  to 
documentation  items 
currently  in  the 
library 

are  reviewed.  (L3-22,  A6,  3) 

Software  process- 
related 

documentation  or 
documentation  items 

□  are  catalogued  for  easy  access. 
(L3-22,  A6,  2) 

□  are  reviewed  periodically.  (L3- 
22,  A6,  5) 
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OPD  Process  -  Exit  Criteria,  Continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  organization  process  definition  process. 


Condition 

References 

A  project's  defined  software  process  is  a  tailored  version  of 
the  organization's  standard  software  process.  (L3-13,  Cl,  2) 

Information  collected  from  the  projects  is  organized  and 
used  to  improve  the  organization's  standard  software 
process.  (L3-13,  Cl,  4) 

Changes  proposed  for  the  descriptions  of  software  life  cycles 
are  documented,  reviewed,  and  approved  by  the  group 
responsible  for  the  organization’s  software  process 
activities  (e.g.,  software  engineering  process  group)  before 
they  are  incorporated.  (L3-18,  A3,  2) 

Changes  proposed  for  the  tailoring  guidelines  and  criteria 
are  documented,  reviewed,  and  approved  by  the  group 
responsible  for  the  organization's  software  process 
activities  (e.g.,  software  engineering  process  group)  before 
they  are  incorporated.  (L3-20,  A4,  2) 

The  organization's  software  process  database  is  established 

and  maintained.  (L3-20,  A5) 

□  The  database  is  established  to  collect  and  make  available 
data  on  the  software  processes  and  resulting  software 
work  products. 

□  The  data  entered  into  the  database  are  reviewed  to  ensure 
the  integrity  of  the  database  contents. 

□  The  database  is  managed  and  controlled. 

□  User  access  to  the  database  contents  is  controlled  to 
ensure  completeness,  integrity,  and  accuracy  of  the  data. 

The  software  quality  assurance  group  reviews  and/or  audits 
the  organization's  activities  and  work  products  for 
developing  and  maintaining  the  organization's  standard 
software  process  and  related  process  assets  and  reports  the 
results.  (L3-23,  VI) 

The  appropriate  standards  are  followed  in  developing, 
documenting,  and  maintaining  the  organization's  standard 
software  process  and  related  process  assets.  (L3-23,  VI,  1) 
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OPD  Process  <■  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  organization 
process  definition  process. 


Review  or  Audit 

Review 

Participants 

References 

Changes  proposed  for  the  organization's 
standard  software  process  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g.,  software 
engineering  process  group)  before  they 
are  incorporated.  (L3-16,  Al,  6) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group) 

The  description  of  the  organization's 
standard  software  process  undergoes  peer 
review  when  initially  developed  and 
whenever  significant  changes  or  additions 
are  made.  (L3-16,  Al,  8) 

Not  specified  in 
the  CMM 

Changes  proposed  for  the  descriptions  of 
software  life  cycles  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g.,  software 
engineering  process  group)  before  they 
are  incorporated.  (L3-18,  A3,  2) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group) 

The  descriptions  of  the  software  life  cycles 
undergo  peer  review  when  initially 
documented  and  whenever  significant 
changes  or  additions  are  made.  (L3-19, 

A3,  3) 

Not  specified  in 
the  CMM 

Changes  proposed  for  the  tailoring 
guidelines  and  criteria  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g.,  software 
engineering  process  group)  l^fore  they 
are  incorporated.  {L3-20,  A4,  2) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group) 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L3-Process-41 


OPD  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lis:s  the  recommended  reviews  and  audits  for  the  organization 
process  definition  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

The  data  entered  into  the  (organization's 
software  process)  database  is  reviewed  to 
ensure  the  integrity  of  the  database 
contents.  (L3-21,  A5,  2) 

Not  specified  in 
the  CMM 

Candidate  (software  process-related) 
documentation  items  are  reviewed  and 
appropriate  items  that  may  be  useful  in  the 
future  are  ineluded  in  the  library  (of 
software-process  related  documentation). 
(L3-21,  A6,  1) 

Not  specified  in 
the  CMM 

Revisions  made  to  (software  process- 
related)  documentation  items  currently  in 
the  library  are  reviewed,  and  the  library 
contents  are  updated  as  appropriate.  (L3- 
22,  A6,  3) 

Not  specified  in 
the  CMM 

The  use  of  each  (software  process-related) 
documentation  item  is  reviewed 
periodically,  and  the  results  are  used  to 
maintain  the  library  contents.  (L3-22,  A6, 
5) 

Not  specified  in 
the  CMM 

The  software  quality  assurance  grottp 
reviews  and/or  audits  the  organization’.'-, 
activities  and  work  products  for  developing 
and  maintaining  the  organization’s 
standard  software  process  and  related 
process  assets  and  reports  the  results.  (L3- 
23,  VI) 

At  a  minimum,  these  reviews  and/or  audits 
verify  that: 

□  The  appropriate  standards  are  followed 
in  developing,  documenting,  and 
maiiitaining  the  organization’s  stand  ird 
software  process  and  related  process 
assets. 

□  The  organization’s  standard  software 
process  and  related  process  assets  are 
controlled  and  used  appropriately. 

Software 

quality 

assurance 

group 
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OPD  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  organization  process  definition  process. 


V 

Work  Products  Managed  and  Controlled 

References 

Description  of  the  organization's  standard  software  process.* 
(L3-17,  Al,  9) 

Descriptions  of  the  software  life  cycles.  (L3-19,  A3,  4) 

Tailoring  guidelines  and  criteria.  (L3-20,  A4,  3) 

Organization's  software  process  database.  (L3-21,  A5,  3) 

Library  of  software  process-related  documentation.  (L3-22, 
A6,  6) 

■^Indicates  that  the  CMM  recommends  that  this  item  must  be  placed  under 
configuration  management 
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OPD  Process  -  Measurements 


Measurements 


The  table  below  lists  the  recommended  measurements  for  the  organization  process 
definition  process. 


Measurements 

References 

Data  on  the  software  work  products  (resulting  from  the 
software  process).  (L3-20,  A5,  1) 

Data  on  the  software  processes.  (L3-20,  A5,  1) 

Measurements  to  determine  the  status  of  the  organization's 
process  definition  activities.  (L3-22,  Ml) 

Examples  of  measurements  include: 

□  Status  of  the  schedule  milestones  for  process 
development  and  maintenance. 

□  Costs  for  the  process  definition  activities. 
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OPD  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  organization  process  definition  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


Documented  Procedure(s) 

References 

The  organization's  standard  software  process  is  developed 
and  maintained  according  to  a  documented  procedure.  (L3- 
15,  Al) 
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OPD  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  organization  process 
definition  process. 


T 

Training 

References 

The  individuals  who  develop  and  maintain  the 
organization's  standard  software  process  and  related 
process  assets  receive  required  training  to  perform  these 
activities.  (L3-14,  Ab2) 
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OPD  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  organization  process 
definition  process. 


Tools 

Reference.s 

Tools  to  support  process  development  and  maintenance. 
(L3-14  Abl,2) 

Examples  of  support  tools  include; 

□  desktop  publishing  tools, 

□  database  management  systems,  and 

□  process  modeling  tools. 

State-of-the-practice  software  engineering  fools.  (L3-l.‘5, 
Al,3) 

Organization’s  software  process  database.  (L3-20,  A5) 
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Training  Program  (TP)  Process 
TP  Process  -  Overview 


TP  process 
purpose 


TP  process 
description 


The  purpose  of  the  Training  Program  key  process  area  is  to  develop  the  skills  and 
knowledge  of  individuals  so  they  can  perform  their  roles  effectively  and 
efficiently.  (L3-25) 


Training  Program  involves  first  identifying  the  training  needed  by  the 
organization,  projects,  and  individuals,  then  developing  or  procuring  training  to 
address  the  identified  needs. 

Each  software  project  evaluates  its  current  and  future  skill  needs  and  determines 
how  these  skills  will  be  obtained.  Some  skills  are  effectively  and  efficiently 
imparted  through  informal  vehicles  (e.g.,  on-the-job  training  and  informal 
mentoring),  whereas  other  skills  need  more  formal  training  vehicles  (e.g., 
classroom  training  and  guided  self-study)  to  be  effectively  and  efficiently 
imparted.  The  appropriate  vehicles  are  selected  and  used. 

This  key  process  area  covers  the  practices  for  the  group  performing  the  training 
function.  The  practices  identifying  the  specific  training  topics  (i.e.,  knowledge  or 
skill  needed)  are  contained  in  the  Ability  to  Perform  common  feature  of  the 
individual  key  process  areas.  (L3-25) 


Continued  on  next  page 
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TP  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-5 1 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-52 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-53 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-54 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-55 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-56 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L3-Process-60 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-61 

Measurements 

Description  of  process  measurements. 

L3-Process-62 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-63 

Tiaining 

List  of  training. 

L3-Process-64 

Tools 

List  of  tools. 

L3-Process-65 
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TP  Process  -  Roles 


Roles  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

training  program  process. 


Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

The  organization's  training  plan  is  readily 
available  to  the  affected  groups  and 
individuals.  (L3-31,  A2,  6) 

Affected 

individuals 

□  The  organization’s  training  plan  is 
reviewed  by  the  affected  individuals 
when  it  is  initially  released  and 
whenever  major  revisions  are  made. 
(L3-31,  A2,  4) 

□  The  organization's  training  plan  is 
readily  available  to  the  affected  groups 
and  individuals.  (L3-31,  A2,  6) 

Manager 

A  manager  is  designated  to  be  responsible 
for  implementing  the  organization's 
training  program.  (L3-28,  Ab2,  1) 

_ I 

Senior 

management 

The  training  program  activities  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3-35,  VI) 

Software 

manager 

Software  managers  receive  orientation  on 
the  training  program.  (L3-29,  Ab4) 

Training 

group 

Members  of  the  training  group  have  the 
necessary  skills  and  knowledge  to  perform 
their  training  activities.  (L3'28,  Ab3) 
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TP  Process  -  Entry  Criteria 


Input-based  There  are  no  input-based  entry  criteria  in  the  training  program  process, 
entry  criteria 


General  entry  The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
criteria  before  entering  the  training  program  process. 


Condition 

References 

The  organization  follows  a  written  policy  for  meeting  its 
training  needs.  (L3-26,  Cl) 

[Refer  to  Level  3  Policies  for  additional  information 
regarding  TP  policy.] 

A  group  responsible  for  fulfllling  the  training  needs  of  the 
organization  exists.  (L3-27,  Abl) 

Adequate  resources  and  funding  are  provided  for 
implementing  the  training  program.  (L3-27,  Ab2) 

A  manager  is  designated  to  be  responsible  for 
implementing  the  organization’s  training  program.  (L3-  28, 
Ab2,  1) 

Tools  to  support  the  training  program  activities  are  made 
available.  (L3-28,  Ab2,  2) 

Appropriate  facilities  are  made  available  to  conduct  training. 
(L3-28,  Ab2,  3) 

Members  of  the  training  group  have  the  necessary  skills  and 
knowledge  to  perform  their  training  activities.  (L3-28,  Ab3) 

Software  managers  receive  orientation  on  the  training 
program.  (L3-29,  Ab4) 
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TP  Process  -  Inputs 


Inputs 


The  table  below  lists  the  lecommended  inputs  to  the  training  program  process. 


Input 

Org.  Input 

References 

Changes  to  the  organization’s  training 
plan.  (L3-31,A2,  3) 

Organization’s  training  plan.  (L3-30,  A2) 

[Refer  to  Level  3  Standards  for  additional 
information  regarding  the  organization’s 
training  plan.] 

Organizational  standards  for  training 
cou  'ses.  (L3-33,  A4) 

[Refer  to  Level  3  Standards  for  additional 
information  regarding  organizational 
standards  for  training.} 

Procedures  for  collecting,  reviewing,  and 
using  training  evaluations  and  other 
training  feedback.  (L3-33,  A3,  7.4) 

Procedures  for  maintaining  records  of  the 
training  provided.  (L3-33,  A3,  7.3) 

Procedures  for  registering  and 
participating  in  the  training.  (L3-33,  A3, 
7.2) 

Procedures  for  selecting  the  individuals 
who  will  receive  the  training.  (L3-33,  A3, 
7.1) 

Skills  needed  by  the  organization  and 
when  those  skills  are  needed.  (L3-30,  A2, 

2) 

Software  projects’  training  needs.  (L3-29, 
Al) 

Standards  for  instructional  materials  used 
in  training  courses.  (L3-32,  A3,  4) 

Training  courses  prepared  at  the 
organizational  level.  (L3-33,  A4) 

Training  evaluations.  (L3-33,  A3,  7.4) 

Training  plan  (for  each  software  project). 
(L3-29,  Al) 

Waiver  procedure  for  required  training. 
(L3-34,  A5) 
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TP  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  training  program  process. 


Activities 

References 

Each  software  project  develops  and  maintains  a  training  plan 
that  specifies  its  training  needs.  (L3-29,  Al) 

The  organization's  training  plan  is  developed  and  revised 
according  to  a  documented  procedure.  (L3-30,  A2) 

[Refer  to  Level  3  Procedures  for  additional  information.] 

The  training  for  the  organization  is  performed  in 
accordance  with  the  organization's  training  plan.  (L3-32, 

A3) 

Training  courses  prepared  at  the  organization  level  are 
developed  and  maintained  according  to  organization 
standards.  (L3-33,  A4) 

A  waiver  procedure  for  required  training  is  established  and 
used  to  determine  whether  individuals  already  possess  the 
knowledge  and  skills  required  to  perform  in  their  designated 
roles.  (L3-34,  A5) 

Records  of  training  are  maintained.  (.L3-34,  A6) 

□  Records  are  kept  of  all  students  who  successfully 
complete  each  training  course  or  other  approved 
training  activity. 

□  Records  are  kept  of  all  students  who  successfully 
complete  their  designated  required  training. 

□  Records  of  successfully  complete  i  training  are  made 
available  for  consideration  in  assignments  of  the  staff 
and  managers. 

Measurements  are  made  and  used  to  determine  the  status  of 
the  training  program  activities.  (L3-34,  Ml) 

Measurements  are  made  and  used  to  determine  the  quality 
of  the  training  program.  (L3-35,  M2) 

The  training  program  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L3-35,  VI) 

The  training  program  is  independently  evaluated  on  a 
periodic  basis  for  consistency  with,  and  relevance  to,  the 
organization's  needs.  (L3-36,  V2) 

The  training  program  activities  and  work  products  are 
reviewed  and/or  audited  and  the  results  are  reported.  (L3- 
36,  V3) 

[Refer  to  TP  Process  Reviews  and  Audits  for  additional 
information] 
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TP  Process  -  Outputs 


Outputs 


Ti;e  table  below  lists  the  recommended  outputs  produced  by  the  training  program 
process. 


V 

Output 

Org.  Outputs 

References 

Description  of  each  training  course.  (L3- 
33,  A4,  1) 

Materials  for  the  training  course.  (L3-33, 
A4,  2) 

Measurements.  (L3-34,  MI) 

Needed  skills  and  knowledge  for  each 
software  management  role.  (L3-26,  Cl,  1) 

Needed  skills  and  knowledge  for  each 
technical  role.  (L3-26,  Cl,  1) 

Organization’s  training  plan.  (L3-30,  A2) 

Records  of  all  students  who  successfully 
complete  each  training  course  or  other 
approved  training  activity.  {L3-34,  A6,  1) 

Records  of  all  students  who  successfully 
complete  their  designated  required 
training.  (L3-34,  A6,  2) 

Records  of  successfully  completed 
training.  (L3-34,  A6,  3) 

Records  of  training  or  training  records. 
(L3-34,  A6) 

Results  of  reviews  and/or  audits  of  the 
training  program  activities  and  work 
products.  (L3-36,  V3) 

Specific  training  to  be  provided.  (L3-30, 
A2,  2) 

Training  courses  prepared  at  the 
organization  level.  (L3-33,  A4) 

Training  plan  (for  each  software  project). 
(L3-29,  Al) 

Training  program  work  products.  (L3-36, 
V3) 

Training  vehicles  for  imparting  skills  and 
knowledge.  (L3-26,  Cl,  2) 

Waiver  procedure  for  required  training. 
(L3-34,  A5) 
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TP  Process  -  Exit  Criteria 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
exit  criteria  to  exit  the  training  program  process. 


Output 

Description  of  each 
training  course 

Materials  for  the 
training  course 

Measurements 


Needed  skills  and 
knowledge  for  each 
software  management 
role 

Needed  skills  and 
knowledge  for  each 
technical  role 


References 


is  developed.  (L3-33,  A4,  1) 

□  are  reviewed.  (L3-33,  A4,  2) 

□  are  managed  and  controlled. 

(L3-34.  A4,  3) _ 

□  are  made  to  determine  the  status 
of  the  training  program  activities. 
(L3-34,  Ml) 

□  are  used  to  determine  the  status 
of  the  training  program  activities. 
(L3-34,  Ml) 

□  are  made  to  determine  the 
quality  of  the  training  program. 
(L3-35,  M2) 

! 

□  are  used  to  determine  the  quality 

of  the  training  program.  (L3-35, 
M2) _ 

are  identified.  (L3-26,  Cl,  1) 


are  identified.  (L3-26,  Cl,  1) 


:nces 


Continued  on  next  page 
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TP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  training  program  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Organization’s 
training  plan 

□  is  developed  according  to  a 
documented  procedure.  (L3-30, 
A2) 

□  is  revised  according  to  a 
documented  procedure.  (L3-30, 
A2) 

□  uses  the  software  projects' 
training  needs  identified  in  their 
training  plans.  (L3-30,  A2,  1) 

□  is  revised,  as  appropriate,  to 
incorporate  changes.  (L3-31, 

A2,  3) 

□  IS  reviewed  by  the  affected 
individuals  when  it  is  initially 
released  and  whenever  major 
revisions  are  made.  (L3-31,  A2, 

4) 

□  is  managed  and  controlled.  (L3- 
31,  A2,  5) 

□  is  readily  available  to  the  affected 
groups  and  individuals.  (L3-31, 
A2,  6) 

Records  of  all 
students  who 
successfully  complete 
each  training  course 
or  other  approved 
training  activity 

are  kept.  (L3*34,  A6,  1 ) 

Records  of  all 
students  who 
successfully  complete 
their  designated 
required  training 

are  kept.  (L3-34,  A6,  2) 

Records  of 
successfully 
completed  training 

are  made  available  for  consideration 
in  assignments  of  the  staff  and 
managers.  (L3-34,  A6,  3) 

Records  of  training 
or  training  records 

are  properly  maintained.  (L3-36, 

V3,  3) 

Continued  on  next  page 
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TP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  training  program  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Results  of  reviews 
and/or  audits  of  the 
training  program 
activities  and  work 
products 

are  reported.  (L3-36,  V3) 

Specific  training  to 
be  provided 

is  identified  based  on  the  skills 
needed  by  the  organization  and 
when  those  skills  are  needed.  (L3- 
30.  A2.  2) 

Training  courses 
prepared  at  the 
organization  level 

□  are  developed  according  to 
organization  standards.  (L3-33, 
A4) 

□  are  maintained  according  to 
organization  standards.  (L3-33, 
A4) 

Training  plan  (for 
each  software 
project) 

□  is  developed.  (L3-29,  Al) 

□  is  maintained.  (L3-29,  Al) 

□  specifies  the  software  project’s 
training  needs.  (L3-29,  Al) 

Training  program 
work  products 

□  are  reviewed.  (L3-36,  V3) 

□  are  audited.  (L3-36,  V3) 

Training  vehicles  for 
imparting  skills  and 
knowledge 

□  are  identified.  (L3-26,  Cl,  2) 

□  are  approved.  (L3-26.  Cl,  2) 

Waiver  procedure  for 
required  training 

□  is  established.  (L3-34,  A5) 

□  is  used  to  determine  whether 
individuals  already  possess  the 
knowledge  and  skills  required  to 
perform  in  their  designated  roles. 
(L3-34,  A5) 
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TP  Process  -  Exit  Criteria,  Continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  training  program  process. 


Condition 

References 

The  training  for  the  organization  is  performed  in 
accordance  with  the  organization's  training  plan.  (L3-32, 

A3) 

The  training  program  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L3-35,  VI) 

The  training  program  is  independently  evaluated  on  a 
periodic  basis  for  consistency  with,  and  relevance  to,  the 
organization's  needs.  (L3-36,  V2) 

The  training  program  activities  and  work  products  are 
reviewed  anchor  audited  and  the  results  are  reported.  (L3- 
36,  V3) 

CMU/SEI-94-HB-1 


L3-Process-59 


TP  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  training  program 
process. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  organization’s  training  plan  is  reviewed 
by  the  affected  individuals  when  it  is 
initially  released  and  whenever  major 
revisions  are  made.  (L3-31,  A2,  4) 

Affected 

individuals 

The  materials  for  the  training  course  are 
reviewed.  (L3-33,  A4,  2) 

Not  specified  in 
theCMM 

The  training  program  activities  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3-35,  V!) 

Senior 

management 

The  training  program  is  independently 
evaluated  on  a  periodic  basis  for 
consistency  with,  and  relevance  to,  the 
organization's  needs.  (L3-36,  V2) 

Not  specified  in 
the  CMM 

The  training  program  activities  and  work 
products  are  reviewed  and/or  audited  and 
the  results  are  reported.  (L3-36,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify  that: 

□  The  process  for  developing  and 
revising  the  organization's  training  plan 
is  followed. 

□  The  process  for  developing  and 
revising  a  training  course  is  followed. 

□  Training  records  are  properly 
maintained. 

□  Individuals  designated  as  requiring 
specific  training  complete  that  training. 

□  The  organization’s  training  plan  is 
followed.. 

Not  specified  in 
the  CMM 
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TP  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  training  program  process. 


V 

Work  Products  Managed  and  Controlled 

References 

The  organization’s  training  plan.  (L3-31,  A2,  5) 

The  materials  for  the  training  courses.  (L3-34,  A4,  3) 
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TP  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  training  program 
process. 


V 

Measurements 

References 

Measurements  to  determine  the  status  of  the  training 
program  activities.  (L3-34,  Ml) 

Examples  of  measurements  include: 

□  Actual  attendance  at  each  training  course  compared  to 
the  projected  attendance. 

□  Progress  in  providing  training  courses  compared  to  the 
organization’s  and  projects’  training  plans. 

□  Number  of  training  waivers  approved  over  time. 

Measurements  to  determine  the  quality  of  the  training 
program.  (L3-35,  M2) 

Examples  of  measurements  include; 

□  Results  of  post-training  tests. 

□  Reviews  of  the  courses  from  the  students. 

□  Feedback  from  the  software  managers. 
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TP  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  training  program  process  recommended 
to  be  performed  according  to  a  documented  procedure. 


Documented  Procedure(s) 

References 

The  organization's  training  plan  is  developed  and  revised 
according  to  a  documented  procedure.  (L3-30,  A2) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 
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TP  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  training  prograro  process. 


V 

Training 

References 

Software  managers  receive  orientation  on  the  training 
program.  (L3-29,  Ab4) 
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TP  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  training  program  process. 


V 

Tools 

References 

Tools  to  support  the  training  program  activities.  (L3-28, 

Ab2,  2) 

Examples  of  support  tools  include- 

□  workstations, 

□  instructional  design  tools, 

□  database  programs,  and 

□  packages  for  developing  presentation  materials. 
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Integrated  Software  Management  (ISM)  Process 
ISM  Process  -  Overview 


ISM  process 
purpose 


ISM  process 
description 


The  purpose  of  Integrated  Software  Management  is  to  integrate  the  software 
engineering  and  management  activities  into  a  coherent,  defined  software  process 
that  is  tailored  from  the  organization's  standard  software  process  and  related 
process  assets,  which  are  described  in  Organization  Process  Definition.  (L3-37) 


Integrated  Software  Management  involves  developing  the  project's  defined 
software  process  and  managing  the  software  project  using  this  defined  software 
process.  The  project's  defined  software  process  is  tailored  from  the  organization's 
standard  software  process  to  address  the  specific  characteristics  of  the  project. 

The  software  development  plan  is  based  on  the  project's  defined  software  process 
and  describes  how  the  activities  of  the  project's  defined  software  process  will  be 
implemented  and  managed.  The  management  of  the  software  project's  size,  effort, 
cost,  schedule,  staffing,  and  other  resources  is  tied  to  the  tasks  of  the  project's 
defined  software  process. 

Since  the  projects'  defined  software  processes  are  all  tailored  from  the 
organization's  standard  software  process,  the  software  projects  can  share  process 
data  and  lessons  learned. 

The  basic  practices  for  estimating,  planning,  and  tracking  a  software  project  are 
described  in  the  Software  Project  Planning  and  Software  Project  Tracking  and 
Oversight  key  process  areas.  They  focus  on  recognizing  problems  when  they 
occur  and  adjusting  the  plans  and/or  performance  to  address  the  problems.  The 
practices  of  this  key  process  area  build  on,  and  are  in  addition  to,  the  practices  of 
those  two  key  process  areas.  The  emphasis  of  Integrated  Software  Management 
shifts  to  anticipating  problems  and  acting  to  prevent  or  minimize  the  effects  of 
these  problems.  (L3-37) 


Continued  on  next  page 
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ISM  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-69 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-72 

Inputs 

Description  of  the  work  p'oducts  used  by 
the  process. 

L3-Process-73 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-75 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-78 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-83 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L3-Process-95 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-98 

Measurements 

Description  of  process  measurements. 

L3-Process-99 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-100 

Training 

List  of  training. 

L3-Process-101 

Tools 

List  of  tools. 

L3-Process-102 
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ISM  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
integrated  software  management  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

The  software  engineering  group  and  other 
affected  groups  and  individuals  are 
included  in  the  communications  on  the 
software  risks,  the  software  risk 
management  plans,  and  the  results  of  risk 
mitigation.  (L3-55,  AlO,  7) 

Affected 

individuals 

The  software  engineering  group  and  other 
affected  groups  and  individuals  are 
included  in  the  communications  on  the 
software  risks,  the  software  risk 
management  plans,  and  the  results  of  risk 
mitigation.  (L3-55,  AlO,  7) 

Customer 

Waivers  for  deviations  from  contractual 
software  process  requirements  are 
documented  and  are  reviewed  and 
approved  by  senior  management  and  the 
software  project’s  customer,  as  appropriate. 
(L3-42,  Al,  4) 

Group 

responsible  for 

coordinating 

the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process 

group) 

Tailonng  of  the  organization's  standard 
software  process  for  the  project  is  reviewed 
by  the  group  responsible  for  coordinating 
the  organization’s  software  process 
activities  (e.g.,  software  engineering 
process  group)  and  approved  by  senior 
management.  (L3-42,  Al,  3) 

Group  that  is 
independent  of 
the  software 
engineering 
group 

A  group  that  is  independent  of  the 
software  engineering  group  reviews  the 
procedures  for  estimating  the  size  of  the 
software  work  products,  and  provides 
guidance  in  using  historical  data  from  the 
organization’s  software  process  database  to 
establish  credible  estimates.  (L3-47,  A6,  I ) 

Individuals 
who  prepare 
the  size 
estimates 

The  individuals  who  prepare  the  size 
estimates  ensure  that  the  procedures  and 
data  used  in  the  estimates  are  appropriate. 
(L3-48,  A6,  1.1) 
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ISM  Process  -  Roles,  continued 


Role:, 

continued 


The  table  below  list?  the  roles  and  the  activities  in  which  they  participate  in  the 
integrated  software  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Individuals 

responsible  for 

il.  "eloping  the 

project's 

defined 

software 

process 

The  individuals  responsible  for  developing 
the  project's  defined  software  process 
receive  required  training  in  how  to  tailor 
the  organization's  standard  software  process 
and  use  the  related  process  assets.  (L3-39, 
Ab2) 

Project 

manager 

The  activities  for  managing  the  software 
project  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-57,  V2) 

Senior 

management 

□  Tailoring  of  the  organization's  'f^ndard 
software  process  for  the  project . 
reviewed  by  the  group  responsible  for 
coordinating  the  organization's 
software  process  activities  (e.g., 
software  engineering  process  group) 
and  approved  by  senior  management. 
(L3-42.  Al,  3) 

□  Waivers  for  deviations  from  the 
organization’s  standard  software 
process  are  documented  and  are 
reviewed  and  approved  by  senior 
ijtCnagement .  (L3-42,  Al,  3.1) 

□  Waivers  for  deviations  from  contractual 
software  process  requirements  are 
documented  and  are  reviewed  and 
approved  by  senior  management  and 
the  software  project's  customer,  as 
appropriate.  (L3-42,  Al,  4) 

□  The  activities  for  managing  the 
software  project  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L3-56,  VI) 

Software 

engineering 

group 

The  software  engineering  group  and  other 
affected  groups  and  individuals  are 
included  in  the  communications  on  the 
software  risks,  the  software  risk 
management  plans,  and  the  results  of  risk 
mitigation.  (L3-51  AlO,  7) 
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ISM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
integrated  software  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software 

manager 

The  software  managers  receive  required 
training  in  managing  the  technical, 
administrative,  and  personnel  aspects  of  the 
software  project  based  on  the  project's 
defined  software  process.  (L3-40,  Ab3) 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  managing  the  software  project 
and  reports  the  results.  (L3-57,  V3) 

Team  of  peers 
and  experts 

_ 

When  the  validity  of  a  size  estimate  is 
questioned,  a  team  of  peers  and  experts 
reviews  the  estimate.  (L3-48,  A6,  1 .2) 
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ISM  Process  -  Entry  Criteria 


Input-based  The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
entry  criteria  before  entering  the  integrated  software  management  process. 


V 

Input 

State 

References 

Available  capacity 
for  the  critical 
computer  resources 

provides  for  a  specified  reserve 
capacity  when  the  initial  estimates  are 
made.  (L3-5I,  A8,  4) 

Software  effort,  cost, 
and  staffing  profile 
models 

□  if  used,  are  adapted  to  the 
project.  (L3-49,  A7,  1) 

□  use  available  historical  data 
where  appropriate.  (L3-49,  A7, 

1) 

Software  schedule 

identifies  specific  tasks  and 
milestones  whose  completion  can  be 
objectively  determined  (i.e.,  a  binary 
or  yes/no  determination).  (L3-5 1 , 

A9,  1.1) 

General  entry  The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
criteria  before  entering  the  integrated  software  management  process. 


Condition 

References 

The  project  follows  a  written  organizational  policy  requiring 
that  the  software  project  be  planned  and  managed  using  the 
organization's  standa-d  software  process  and  related  process 
assets.  (L3-38,  Cl) 

Adequate  resources  and  funding  are  provided  for  managing 
the  software  project  using  the  project's  defined  software 
process.  (L3-39,  Abl) 

The  individuals  responsible  for  developing  the  project's 
defined  software  process  receive  required  training  in  how  to 
tailor  the  organization’s  standard  software  process  and  use 
the  related  process  assets.  (L3-39,  Ab2) 

The  software  managers  receive  required  training  in 
managing  the  technical,  administrative,  and  personnel 
aspects  of  the  software  project  based  on  the  project's  defined 
software  process.  (L3-40,  Ab3) 
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ISM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  integrated  software 
management  process. 


V 

Input 

Org.  Input 

References 

Actual  data  on  project  productivity  and 
other  new  software  costs.  (L3-50,  A7,  4.2) 

Available  capacity  for  the  critical  computer 
resources.  (L3-51,  A8,  4) 

Available  computer  resources.  (L3-50,  A8, 
3) 

Available  historical  data.  (L3-49,  A7,  1) 

Changes  proposed  by  the  software  project 
(to  the  project’s  defined  software  process). 
(L3-43,  A2,  1.2) 

Critical  dependencies  of  the  project’s 
software  schedule.  (L3  51,  A9) 

Critical  paths  of  the  project's  software 
schedule.  (L3-51,  A9) 

Data  for  similar  software  projects.  (L3-46, 
A5,  1) 

Historical  data  from  the  organization's 
software  process  database.  (L3-47,  A6,  1) 

Historical  experience,  simulations, 
prototyping,  or  analysis.  (L3-50,  A8,  1) 

Lessons  learned  (management)  from 
monitoring  the  activities  of  other  projects 
in  the  organization.  (L3-45,  A4,  6) 

Lessons  learned  (technical)  from 
monitoring  the  activities  of  other  projects 
in  the  organization.  (L3-45,  A4,  6) 

Lessons  learned  from  monitoring  the 
software  activities  of  the  organization’s 
projects.  (L3-43,  A2,  1.1) 

Organization's  library  of  software  procc  s- 
related  documentation.  (L3-45,  A4,  5) 

Organization's  software  process  database. 
(L3-39,  Cl,  4) 

Organization's  standard  software  process. 
(L3-38,  Cl) 

. 
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ISM  Process  -  Inputs,  Continued 


Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  integrated  software 
management  process,  continued  from  the  previous  page. 


Input 

Org.  Input 

References 

Organisation's  standards.  (L3-41,  Al,  1.3) 

Organization's  tailoring  guidelines  and 
criteria  (for  the  organization’s  standard 
software  process).  (L3-41,  Al,  1.2) 

Planned  computer  resources.  (L3-50,  A8, 

2) 

Process  and  work  product  measurement 
data.  (L3-43,  A2,  1.3) 

Project's  contractual  and  operational 
constraints.  (L3-41,  Al,  1.1) 

Project's  critical  computer  resource 
requirements.  (L3-50,  A8,  2) 

Project's  critical  computer  resources.  (L3- 
50,  A8) 

Project's  defined  software  process.  (L3-39, 
Cl,  3) 

Project's  software  development  plan.  (L3- 
44,  A3) 

Project's  software  risks.  {L3-52,  A 10) 

Related  process  assets.  (L3-38,  Cl) 

Risk  priorities.  (L3-55,  AlO,  6.1) 

Software  design.  (L3-50,  A8,  2) 

Software  effort,  cost,  and  staffing  profile 
models.  (L3-49,  A7,  1) 

Software  requirements.  (L3-50,  A8,  2) 

Software  risk  management  plan.  CLS-SS, 
AlO,  1) 

Software  schedule.  (L3-5I,  A9,  1.1) 

Specific  needs  of  the  software  project. 
(L3-45,  A4,  8) 

System  requirements  allocated  to  software. 
(L3-50,  A8,  2) 
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ISM  Process  -  Activities 


Activities 


The  table  below  lists  the  required  activities  for  the  integrated  software  management 
process. 


I 

V 

Activities 

References  j 

The  project's  defined  software  process  is  de'  eloped  by 
tailoring  the  organization's  standard  software  process 
according  to  a  documented  procedure.  (L3-41,  Al) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Each  project's  defined  software  process  is  revised  according 
to  a  documented  procedure.  (L3-43,  A2) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  development  plan,  which  describes  the 
use  of  the  project's  defined  software  process,  is  developed 
and  revised  according  to  a  documented  procedure.  (L3-44, 
A3) 

The  software  project  is  managed  in  accordance  with  the 
project's  defined  software  process.  (L3-44,  A4) 

[Refer  to  Level  3  Standards  for  additional  information 
regarding  the  project's  defined  software  process.] 

The  organization's  software  process  database  is  used  for 
software  planning  and  estimating.  (L3-46,  A5) 

□  The  database  is  used  as  a  source  of  data  to  estimate,  plan, 
track,  and  replan  a  software  project;  data  for  similar 
software  projects  are  used  when  possible. 

□  Parameter  values  used  to  derive  estimates  for  software 
size,  effort,  cost,  schedule,  and  use  of  critical  computer 
resources  are  compared  to  those  of  other  software 
projects  to  assess  their  validity. 

□  Similarities  and  differences  to  the  other  projects  in 
terms  of  application  domain  and  design  approach 
are  assessed  and  recorded. 

□  Rationales  for  similarities  and  differences  betv/een 
the  parameter  values  are  recorded. 

□  The  reasoning  used  to  Judge  the  credibility  of  the 
project's  estimates  is  recorded. 

□  The  software  project  provides  appropriate  software 
planning  data,  replanning  data,  and  actual  measured  data 
for  storage  in  the  organization's  software  process 
database. 

Continued  on  next  page 
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ISM  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  integrated  software 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  size  of  the  software  work  products  (or  size  of  changes  to 
the  software  work  products)  is  managed  according  to  a 
documented  procedure.  (L3-47,  A6) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  effort  and  costs  are  managed 
according  to  a  documented  procedure.  (L3-48,  A7) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  critical  computer  resources  are  managed 
according  to  a  documented  procedure.  (L3-50,  A8) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  critical  dependencies  and  critical  paths  of  the  project’s 
software  schedule  are  managed  according  to  a  documented 
procedure.  (L3-51,  A9) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  risks  are  identified,  assessed, 
documented,  and  managed  according  to  a  documented 
procedure.  (L3-52,  AlO) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Reviews  of  the  software  project  are  periodically  performed 
to  determine  the  actions  needed  to  bring  the  software 
project's  performance  and  results  in  line  with  the  current  and 
projected  needs  of  the  business,  customer,  and  end  users,  as 
appropriate.  (L3-55.  All) 

Measurements  are  made  and  used  to  determine  the 
effectiveness  of  the  integrated  software  management 
activities.  (L3-56,  Ml) 

The  activities  for  managing  the  software  project  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L3-56,  VI) 

Continued  on  next  page 
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ISM  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  integrated  software 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  activities  for  managing  the  software  project  are  reviewed 
with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-57,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  managing  the  software 
project  and  reports  the  results.  (L3-57,  V3) 

[Refer  to  ISM  Process  Reviews  and  Audits  for  additional 
information.] 
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Outputs 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process. 


V 

Output 

Org.  Outputs 

References 

Actions  needed  to  bring  the  software 
project's  performance  and  results  in  line 
with  the  current  and  projected  needs  of  the 
business,  customer,  and  end  users.  (L3-55, 
All) 

Actual  expenditures  over  time  and  against 
work  completed.  (L3-49,  A7,  4) 

Actual  measured  data  (from  the  software 
project).  (L3-47,  A5,  3) 

Alternatives  for  each  software  risk.  {L3-54, 
AlO,  3) 

Changes  to  the  project's  defined  software 
process  derived  from  changes  proposed  by 
the  software  project.  (L3-43,  A2,  1 .2) 

Changes  to  the  project's  defined  software 
process  derived  from  lessons  learned  from 
monitoring  the  software  activities  of  the 
organization’s  projects.  (L3-43,  A2,  1.1) 

Changes  to  the  project's  defined  software 
process  derived  from  process  and  work 
product  measurement  data.  (L3-43,  A2, 

1.3) 

Changes  to  the  project’s  defined  software 
process.  (L3-43,  A2,  2) 

Commitments.  (L3-51,  A9,  1) 

Completion  criteria  (for  key  tasks).  (L3- 
44,  A4,  3) 

Contingency  factor  applied  to  the  size 
estimate  (of  the  software  work  product)  for 
each  software  element  identified  as  a 
software  risk.  (L3-48,  A6,  2) 

Costs.  (L3-51,  A9,  1) 

Criteria  for  selecting  among  the  alternatives 
for  each  software  risk.  (L3-54,  AlO,  3) 

Critical  dependencies  (of  the  project’s 
software  schedule).  (L3-5 1 ,  A9,  2) 

Description  of  the  project’s  defined 
software  process.  (L3-41,A1,2) 
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iSM  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process,  continued  from  the  previous  page. 


Output 

Org.  Outputs 

References 

Documented  criteria  to  indicate  when  to 
replan  the  software  project.  (L3-45,  A4,  4) 

Effort  and  cost  threshold  for  each 
individually  managed  software  task  or 
stage.  (L3-50,  A7,  5) 

Effort  to  modify  and  incorporate  reusable 
components.  (L3-48,  A6,  3.2) 

Estimates  for  the  project's  critical  computer 
resources.  (L3-50.  A8,  1) 

Factors  which  could  significantly  affect  the 
size  of  the  software  work  products.  (L3- 
48,  A6,  4) 

Information  obtained  from  monitoring  the 
(software)  risks.  (L3-55,  A 10,  6.2) 

Initial  release  of  the  software  risk 
management  plan.  (L3-54,  A 10,  4) 

Lessons  learned  (management).  (L3-45, 

A4,  5) 

Lessons  learned  (technical).  (L3-45,  A4, 

5) 

Lessons  learned  from  monitoring  the 
software  activities  of  the  organization’s 
projects.  (L3-43,  A2,  1.1) 

Major  revisions  to  the  software  risk 
management  plan.  (L3-54,  A 10,  4) 

Measurement  data  needed  to  manage  the 
software  project.  (L3-44,  A4,  1) 

Measurements  (to  determine  the 
effectiveness  of  the  integrated  software 
management  activities).  (L3-56,  Ml) 

Milestones.  (L3-51,A9,  1) 

Organization's  software  process  database. 
(L3-46,  A5) 

Overall  software  effort  and  cost.  (L3-49, 
A7,  3) 

Parameter  values  of  the  models  used  in 
estimating  software  effort  and  costs.  (L3- 
50,  A7,  4.1) 

j _ 
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ISM  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process,  continued  from  the  previous  page. 


Output 

Org.  Outputs 

References 

Parameter  values  used  to  derive  estimates 
for  software  size,  effort,  cost,  schedule,  and 
use  of  critical  computer  resources.  (L3-46, 
A5,  2) 

Productivity  and  cost  data.  (L3-49,  A7,  2) 

Project  measurement  data.  (L3-39,  Cl,  4) 

Project's  defined  software  process.  (L3-39, 
Cl,  1) 

Project's  deviations  from  the  organization's 
standard  software  process.  (L3-39,  Cl,  2) 

Project's  software  costs.  (L3-48,  A7) 

Project's  software  development  plan.  (L3- 
44,  A3) 

Project's  software  effort.  {L3-48,  A7) 

Project's  software  risl's.  (L3-52,  A 10) 

Rationale  for  the  contingency  (for  each 
software  element  identified  as  a  software 
risk).  (L3-48,  A6,  2.1) 

Rationales  for  similarities  and  differences 
between  the  parameter  values  (used  to 
derive  estimates  for  software  size,  effort, 
cost,  schedule,  and  use  of  critical  computer 
resources).  (L3-46,  A5,  2.2) 

Readiness  criteria  (for  key  tasks).  (L3-44, 
A4,  3) 

Reasoning  used  to  judge  the  credibility  of 
the  estimates  for  the  project’s  critical 
computer  resources.  (L3-50,  A8,  1 .3) 

Reasoning  used  to  judge  the  credibility  of 
the  project's  estimates  (for  software  size, 
effort,  cost,  schedule,  and  use  of  critical 
computer  resources).  (L3-47,  A5,  2.3) 

Replanning  data  (from  the  software 
project).  (L3-47,  A5,  3) 

Results  of  software  quality  assurance 
reviews  and/or  audits  of  software  project 
activities  and  work  products.  (L3-57,  V3) 

Reuse  measurements.  (L3-48,  A6,  3.1) 
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Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process,  continued  from  the  previous  page. 


V 

Output  1 

Org.  Outputs 

References 

Risks  associated  with  reducing  or 
eliminating  the  contingency  (for  each 
software  element  identified  as  a  software 
risk).  (L3-48,  A6,  2.2) 

Schedule  critical  paths.  (L3-52,  A9,  3) 

Similarities  and  differences  between  the 
project  and  the  sources  for  historical  data 
in  terms  of  application  domain  and  design 
approach.  (L3-50,  A8,  1.2) 

Similarities  and  differences  to  the  other 
projects  in  terms  of  application  domain 
and  design  approach.  (L3-46,  A5,  2.1) 

Size  estimates.  (L3-48,  A6,  1.1) 

Size  of  changes  to  the  software  work 
products.  (L3-47,  A6) 

Size  of  the  software  work  products.  (L3- 
47,  A6) 

Size  threshold  for  each  managed  software 
element.  (L3-48,  A6,  5) 

Software  effort  and  cost  status.  (L3-49, 

A7,  4) 

Software  life  cycle.  (L3-41,  Al,  1) 

Software  planning  data  (from  the  software 
project).  (L3-47,  A5,  3) 

Software  plans  followed  in  interacting  with 
other  groups.  (L3-45,  A4,  9) 

Software  risk  management  plan.  (L3-53, 
AlO,  1) 

Software  schedule.  (L3-51,  A9,  1.1) 

Sources  and  rationale  for  estimates  (for  the 
project's  critical  computer  resources).  (L3- 
50.  A8,  1.1) 

Staffing  plan.  (L3-45,  A4,  7) 

Staffing.  (L3-51,A9,  1) 

Threshold  criteria  for  each  critical  path. 
(L3-52.  A9,  5) 

Th’^eshold  for  each  critical  computer 
resource.  (L3-5 1 ,  A8,  5) 
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ISM  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process,  continued  from  the  previous  page. 


V 

Output 

Org.  Outputs 

References 

Training  needs.  (L3-45,  A4,  8) 

Waivers  for  deviations  from  contractual 
software  process  requirements.  (L3-42, 
A1.4) 

Waivers  for  deviations  from  the 
organization's  standard  software  process. 
(L3-42,  Al,  3.1) 

Work  products  of  the  project's  defined 
software  process.  (L3-44,  A4,  2) 
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Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process. 


Output 

State 

References 

Actions  needed  to 
bring  the  software 
project's  performance 
and  results  in  line 
with  the  current  and 
projected  needs  of 
the  business, 
customer,  and  end 
users 

are  determined  by  periodic  reviews 
of  the  software  project.  (L3-55, 

All) 

Actual  measured  data 
(from  the  software 
project) 

are  provided  for  storage  in  the 
organization's  software  process 
database  (L3-47,  A5,  3) 

Alternatives  for  each 
software  risk 

are  defined.  (L3-54,  A 10,  3) 

Changes  to  the 
project's  defined 
software  process 

□  are  reviewed.  (L3-43,  A2,  2) 

□  are  approved  before  they  are 
incorporated.  (L3-43,  A2,  2) 

Changes  to  the 
project's  defined 
software  process 
derived  from  changes 
propos'  •'  by  the 
software  project 

□  are  documented.  (L3-43,  A2, 

1.2) 

□  are  systematically  reviewed.  {L3- 
43,  A2,  1.2) 

Changes  to  the 
project's  defined 
software  process 
derived  from  lessons 
learned  from 
monitoring  the 
software  activities  of 
the  organization's 
projects 

□  are  documented.  (L3-43,  A2, 

1.1) 

□  are  systematically  reviewed.  (L3- 
43,  A2,  1.1) 

Changes  to  the 
project's  defined 
software  process 
derived  from  process 
and  work  product 
measurement  data 

□  are  documenied.  {L3-43,  A2, 

1.3) 

□  are  systematically  reviewed.  (L3- 
43,  A2,  1.3) 

Commitments 

are  allocated  in  the  schedule 
consi.stent  with  the  project's  define  ' 
.software  process.  (L3-5 1 ,  A9.  1 ) 
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SQA  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Project 

manager 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  are 
documented  and  resolved  with  the 
appropriate  software  task  leaders, 
software  managers,  or  project 
manager,  where  possible.  (L2-67,  A7, 

1) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 

□  The  SQA  activities  are  reviewed  with 
the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
69,  V2) 

1 

1 

1 

1 

i 

Senior 

management 

□  Senior  management  periodically 
reviews  the  SQA  activities  and  results. 
(L2-61,C1,  3) 

□  The  SQA  activities  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L2-68,  VI) 

Continued  on  next  page 
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SQA  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in...  j  Reference  | 

Senior 

manager 

□  A  senior  manager,  who  is 
knowledgeable  in  the  SQA  role  and  has 
the  authority  to  take  appropriate 
oversight  actions,  is  designated  to 
receive  and  act  on  software 
noncompliance  items.  (L2-62,  Ab2,  2) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 

□  Noncompliance  items  presented  to  the 
senior  manager  are  periodically 
reviewed  until  they  are  resolved.  (L2- 
67,  A7,  3) 

Software 

engineering 

group 

The  SQA  group  periodically  reports  the 
results  of  its  activities  to  the  software 
engineering  group.  (L2-67,  A6) 

Software 

manager 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  are 
documented  and  resolved  with  the 
appropriate  software  task  leaders, 
software  managers,  or  project 
manager,  where  possible.  (L2-67,  A7, 

I) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 
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SQA  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software  task 
leader 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  are 
documented  and  resolved  with  the 
appropriate  software  task  leaders, 
software  managers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1) 

□  Deviations  from  the  software 
development  plan  and  the  designated 
project  standards  and  procedures  not 
resolvable  with  the  software  task 
leaders,  software  managers,  or  project 
manager  are  documented  and 
presented  to  the  senior  manager 
designated  to  receive  noncompliance 
items.  (L2-67,  A7,  2) 

SQA  group 

□  Members  of  the  SQA  group  are 
trained  to  perform  their  SQA  activities. 
(L2-62,  Ab3) 

□  The  SQA  group's  activities  are 
performed  in  accordance  with  the  SQA 
plan.  (L2-64,  A2) 

□  The  SQA  group  participates  in  the 
preparation  and  review  of  the  project's 
software  development  plan,  standards, 
and  procedures.  (L2-65,  A3) 

Role  continues  on  next  page 
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SQA  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  assurance  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

SQA  group, 
continued 

□  The  SQA  group  provides  consultation 
and  review  of  the  plans,  standards,  and 
procedures  with  regard  to:  (L2-66,  A3, 
1) 

□  compliance  to  organizational 
policy, 

□  compliance  to  externally  imposed 
standards  and  requirements  (e.g., 
standards  imposed  by  the  statement 
of  work), 

□  standards  that  are  appropriate  for 
use  by  the  project, 

□  topics  that  should  be  addressed  in 
the  software  development  plan,  and 

□  other  areas  assigned  by  the  project. 

□  The  SQA  group  verifies  that  plans, 
standards,  and  procedures  are  in  place 
and  can  be  used  to  review  and  audit  the 
software  project.  (L2-66,  A3,  2) 

□  The  SQA  group  reviews  the  software 
engineering  activities  to  verify 
compliance.  (L2-66,  A4) 

□  The  SQA  group  audits  designated 
software  .vork  products  to  verify 
compliance.  (L2-66,  A5) 

□  The  SQA  group  periodically  reports 
the  results  o^"  its  activities  to  the 
software  engineering  group.  (L2-67, 
A6) 

□  The  SQA  group  conducts  periodic 
reviews  of  its  activities  and  findings 
with  the  customer’s  SQA  personnel,  as 
appropriate.  (L2-67,  A8) 
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SQA  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  in  the  software  quality  assurance  process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  quality  assurance  process. 


Condition 

References 

The  project  follows  a  written  organizational  policy  for 
implementing  software  quality  assurance  (SQA).  (L2-60, 

Cl) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  SQA  policy.] 

A  group  that  is  responsible  for  coordinating  and 
implementing  SQA  for  the  project  (i.e.,  the  SQA  group) 
exists.  (L2-61,  Abl) 

Adequate  resources  and  funding  are  provided  for 
performing  the  SQA  activities.  (L2-62,  Ab2) 

A  manager  is  assigned  specific  responsibilities  for  the 
project’s  SQA  activities.  (L2-62,  Ab2,  1) 

A  senior  manager,  who  is  knowledgeable  in  the  SQA  role 
and  has  the  authority  to  take  appropriate  oversight  actions,  is 
designated  to  receive  and  act  on  software  noncompliance 
items.  (L2-62,  Ab2,  2) 

All  managers  in  the  SQA  reporting  chain  to  the  senior 
manager  are  knowledgeable  in  the  SQA  role, 
responsibilities,  and  authority.  (L2-62,  Ab2,  2.1) 

Tools  to  support  the  SQA  activities  are  made  available.  (L2- 
62,  Ab2,  3) 

Members  of  the  SQA  group  are  trained  to  perform  their 
SQA  activities.  (L2-62,  Ab3) 

The  members  of  the  software  project  receive  orientation  on 
the  role,  responsibilities,  authority,  and  value  of  the  SQA 
group.  (L2-63,  Ab4) 
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SQA  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  quality  assurance 
process. 


Input 

Org.  Input 

References 

Deliverable  software  products.  (L2'66,  A5, 
1) 

Designated  contractual  requirements.,  (L2- 
66,  A5,  2) 

Designated  procedures.  (L2-66,  A4,  I) 

Designated  software  standards.  (L2-66, 

A4,  1) 

Designated  software  work  products.  (L2- 
66,  A5) 

Externally  imposed  requirements.  (L2-66, 
A3.  1.2) 

Externally  imposed  standards.  (L2-66,  A3, 
1.2) 

Project's  procedures.  (L2-65,  A3) 

Project's  software  development  plan.  (L2- 
65,  A3) 

Project's  standards.  (L2-65,  A3) 

Software  work  products.  (L2-66,  A5,  2) 

SQA  plan.  (L2-64,  A2) 
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SQA  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  software  quality  assurance 
process. 


< 

Activities 

References 

A  SQA  plan  is  prepared  for  the  software  project  according 
to  a  documented  procedure.  (L2-63,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  SQA  group  participates  in  the  preparation  and  review 
of  the  project's  software  development  plan,  standaids,  and 
procedures.  (L2-65,  A3) 

□  The  SQA  group  provides  consultation  and  review  of  the 
plans,  standards,  and  procedures  with  regard  to: 

□  compliance  to  organizational  policy, 

□  compliance  to  externally  imposed  standards  and 
requirements  (e.g.,  standards  required  by  the 
statement  of  work), 

□  standards  that  are  appropriate  for  use  by  the  project, 

□  topics  that  should  be  addressed  in  the  software 
development  plan,  and 

□  other  areas  as  assigned  by  the  project. 

□  The  SQA  group  verifies  that  plans,  standards,  and 
procedures  are  in  place  and  can  be  used  to  review  and 
audit  the  software  project. 

The  SQA  group  reviews  the  software  engineering  activities 

to  verify  compliance.  (L2-66,  A4) 

□  The  activities  are  evaluated  against  the  software 
development  plan  and  the  designated  software  standards 
and  procedures. 

□  Deviations  are  identified,  documented,  and  tracked  to 
closure. 

□  Corrections  are  verified. 

The  SQA  group  audits  designated  software  work  products 

to  verify  compliance.  (L2-66,  A5) 

□  The  deliverable  software  products  are  evaluated  before 
they  are  delivered  to  the  customer. 

□  The  software  work  products  are  evaluated  against  i.ie 
designated  software  standards,  procedures,  and 
contractual  requirements. 

□  Deviations  are  identified,  documented,  and  tracked  to 
closure. 

□  Corrections  are  verified. 

Continued  on  next  page 
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SQA  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  quality  assurance 
process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  SQA  group  periodically  reports  the  results  of  its 
activities  to  the  software  engineering  group.  (L2-67,  A6) 

Deviations  identified  in  the  software  activities  and  software 
work  products  are  documented  and  handled  according  to  a 
documented  procedure.  (L2-67,  A7) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  SQA  group  conducts  periodic  reviews  of  its  activities 
and  findings  with  the  customer's  SQA  personnel,  as 
appropriate.  (L2-67,  A8) 

Measurements  are  made  and  used  to  determine  the  cost  and 
schedule  status  of  the  SQA  activities.  (L2-68,  Ml) 

The  SQA  activities  are  reviewed  with  senior  management  on 
a  periodic  basis.  (L2-68,  VI) 

The  SQA  activities  are  reviewed  with  the  project  manager 
on  a  periodic  and  event-driven  basis.  (L2-69,  V2) 

Experts  independent  of  the  SQA  group  periodically  review 
the  activities  and  software  work  products  of  the  project's 

SQA  group.  (L2-69,  V3) 
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SQA  Piocess  -  Outputs 


Outputs 


The  table  below  lists  the  outputs  produced  by  the  software  quality  assurance 
process. 


V 

Output 

Org.  Output 

References 

Corrections  to  deviations  between  the 
contractual  requirements  and  the 
designated  software  work  products.  (L2- 
67,  A5,  4) 

Corrections  to  deviations  between  the 
designated  software  procedures  and  the 
designated  software  work  products.  (L2- 
67,  A5,  4) 

Corrections  to  deviations  between  the 
designated  software  procedures  and  the 
software  engineering  activities.  (L2-66, 

A4.  3) 

Corrections  to  deviations  between  the 
designated  software  standards  and  the 
designated  software  work  products.  (L2- 
67,  A5,  4) 

Corrections  to  deviations  between  the 
designated  software  standards  and  the 
software  engineering  activities.  ''L2-66, 

A4,  3) 

Corrections  to  deviations  between  the 
software  development  plan  and  the 
software  engineering  activities.  (L2-66, 

A4,  3) 

Deviations  between  the  contractual 
requirements  and  the  designated  software 
work  products.  (L2-67,  A5,  3) 

Deviations  between  the  designated  software 
procedures  and  the  designated  software 
work  products.  (L2-67,  A5,  3) 

Deviations  between  the  designated  software 
procedures  and  the  software  engineering 
activities.  (L2-66  A4,  2) 

Deviations  between  the  designated  software 
standards  and  the  designated  software  work 
products.  (L2-67,  A5,  3) 

Deviations  between  the  designated  software 
standards  and  the  software  engineering 
activities.  (L2-66  A4,  2) 

Continued  on  next  page 
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SQA  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  software  quality  assurance 
process,  continued  from  the  previous  page. 


V 

Output 

Org.  Output 

References 

Deviations  between  the  software 
development  plan  and  the  software 
engineering  activities.  (L2-66  A4,  2) 

Deviations  from  the  designated  project 
procedures.  (L2-67,  A7,  1) 

Deviations  from  the  designated  project 
standards.  (L2-67,  A7,  I) 

Deviations  from  the  software  development 
plan.  (L2-67,  A7,  1) 

Deviations  identified  in  the  software 
activities.  (L2-67,  A7) 

Deviations  identified  in  the  software  work 
products.  (L2-67,  A7) 

Documentation  of  noncompliance  items. 
(L2-67,  A7,  4) 

Measurements  (to  determine  the  cost  and 
schedule  status  of  the  SQA  activities).  (L2- 
68,  Ml) 

Results  of  SQA  group  activities.  (L2-67, 
A6) 

Software  noncompliance  items.  (L2-62, 
Ab2,  2) 

1 

Software  work  products  of  the  SQA 
group.  (L2-69,  V3) 

SQA  findings.  (L2-67,  A8) 

SQA  plan.  (L2-63,  Al) 

[Refer  to  Level  Standards  for  additional 
information  regarding  a  SQA  plan.] 

SQA  results.  (L2-61,C1,3) 
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SQA  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  assurance  process. 


'Ti 

Output 

State 

References 

Corrections  to 
deviations  between 
the  contractual 
requirements  and  the 
designated  software 
work  products 

are  identified.  (L2-67,  A5,  4) 

Corrections  to 
deviations  between 
the  designated 
software  procedures 
and  the  designated 
software  work 
products 

are  identified.  (L2-67,  A5,  4) 

Corrections  to 
deviations  between 
the  designated 
software  procedures 
and  the  software 
engineering  activities 

are  identified.  (L2-66,  A4,  3) 

Corrections  to 
deviations  between 
the  designated 
software  standards 
and  the  designated 
software  work 
products 

are  identified.  (L2-67,  A5,  4) 

Corrections  to 
deviations  between 
the  designated 
software  standards 
and  the  software 
engineering  activities 

are  identified.  (L2-66,  A4,  3) 

Corrections  to 
deviations  between 
the  software 
development  plan 
and  the  software 
engineering  activities 

are  identified.  fL2-66,  A4,  3) 

Deviations  between 
the  contractual 
requirements  and  the 
designated  software 
work  products 

□  are  identified.  (L2-67,  A5,  3) 

□  are  documented.  (L2-67,  A5.  3) 

□  are  tracked  to  closure.  (L2-6' 

A5,  3) 

I 

i 

I 

Continued  on  next  page 
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SQA  Process  -  Exit  Criteria,  Continued 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 

exit  criteria,  to  exit  the  software  quality  assurance  process,  continued  from  the  previous  page. 

continued 


V 

Output 

State 

References 

Deviations  between 
the  designated 
software  procedures 
and  the  designated 
software  work 
products 

□  are  identified.  (L2-67,  A5,  3) 

□  are  documented.  (L2-67,  A5,  3) 

□  are  tracked  to  closure.  (L2-67, 
A5.  3) 

- - 

Deviations  between 
the  designated 
software  procedures 
and  the  software 
engineering  activities 

□  are  identified.  (L2-66,  A4,  2) 

□  are  documented.  (L2-66,  A4,  2) 

□  are  tracked  to  closure.  (L2-66, 
A4,  2) 

Deviations  between 
the  designated 
software  standards 
and  the  designated 
software  work 
products 

□  are  identified.  (L2-67,  A5,  3) 

□  are  documented.  (L2-67,  A5,  3) 

□  are  tracked  to  closure.  (L2-67, 
A5,  3) 

Deviations  between 
the  designated 
software  standards 
and  the  software 
engineering  activities 

□  are  identified.  (L2-66,  A4,  2) 

□  are  documented.  (L2-66,  A4,  2) 

□  are  tracked  to  closure.  (L2-66, 
A4,  2) 

Deviations  between 
the  software 
development  plan 
and  the  software 
engineering  activities 

□  are  identified.  (L2-66,  A4,  2) 

□  are  documented.  (L2-66.  A4,  2) 

□  are  tracked  to  closure.  (L2-66, 
A4.  2) 

Deviations  from  the 
designated  project 
procedures 

□  are  documented.  (L2-67,  A7,  1 ) 

□  are  resolved  with  the  appropriate 
software  task  leaders,  software 
managers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1 ) 

□  not  resolvable  with  the  software 
task  leaders,  software  managers, 
or  project  manager  are 
documented  and  pre.sented  to  the 
senior  manager  designated  to 
receive  noncompliance  items. 
(L2-67,  A7,  2) 

Continued  on  next  page 
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SQA  Process  -  Exit  Criteria,  Continued 


Output-b.'uicd 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  assurance  process,  continued  from  the  previous  page. 


Output 

State 

References 

Deviations  from  the 
designated  project 
standards 

□  are  documented.  (L2-67,  A7,  1) 

□  are  resolved  with  the  appropriate 
software  task  leaders,  software 
managers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1) 

□  not  resolvable  with  the  software 

tpicK  Lqders,  software  managers, 
or  p?  -  jert  manager  are 
’ocumented  ’  •'resented  to  the 
jen«or  manager  designated  to 
r.’L^  ...  ompliance  items. 

(Lz-C  A',;:, 

Deviations  from  the 
soi'iware  development 
plan 

□  are  documented.  (L2-67,  A7,  1) 

□  t:solved  with  the  appropriate 
t'u  .  vare  task  leaders,  software 
m'oitivgers,  or  project  manager, 
where  possible.  (L2-67,  A7,  1) 

n  not  resolvable  with  the  software 

It  aders,  s  ftware  managers, 
.•rprc'  Tii.nager  are 

doc  1  and  presented  to  the 

senior  .  tianager  designated  to 
receive  .'loncompliance  items. 
(L2-67,  A7,  2) 

Devia'ions  identified 
in  the  software 
activities 

□  are  documented.  (L2-67,  A7) 

□  are  handled  accr'  ding  to  a 
documented  procedure.  (L2-67, 
A7) 

Deviations  identified 
in  the  software  work 
products 

□  are  documented.  (L2-67,  A7) 

U  are  handled  according  to  a 
documented  procedure.  (L2-67, 
A7) 

Measurements  (to 
determine  the  cost 
and  schedule  status 
of  the  SQA  activities) 

□  are  made.  (L2-68,  Ml) 

□  are  used.  (L2-68,  Ml) 

Continued  on  next  page 
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SQA  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  assurance  process,  continued  from  the  previous  page. 


Output 

State 

References 

Noncompliance  items 
(presented  to  the 
senior  manager) 

□  are  periodically  reviewed  until 
they  are  resolved.  (L2-67,  A7,  3) 

□  are  documented.  (L2-67,  A7,  4) 

□  documentation  is  managed  and 
controlled.  (L2-67,  A7,  4) 

Results  of  SQA 
group  activities 

are  periodically  reported  to  the 
software  engineering  group.  (L2- 
67.  A6) 

SQA  plan 

□  is  prepared  for  the  software 
project  according  to  a 
documented  procedure.  (L2-63, 
Al) 

□  is  developed  in  the  early  stages 
of,  and  in  parallel  with,  the 
overall  project  planning.  (L2-63, 
Al,  1) 

□  is  reviewed  by  the  affected 
groups  and  individuals.  (L2-63, 
A1.2) 

□  is  managed  and  controlled.  (L2- 
64,  Al,  3) 

SQA  results 

are  reviewed  periodically  by  senior 
management.  (L2-61,  Cl,  3) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  quality  assurance  process. 


Condition 

References 

The  SQA  group's  activities  are  performed  in  accordance 
with  the  SQA  plan.  (L2-64,  A2) 

Continued  on  next  page 
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SQA  Process  -  Exit  Criteria,  continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  quality  assurance  process,  continued  from  the  previous  page. 


Condition 

References 

The  SQA  group  participates  in  the  preparation  and  review 
of  the  project's  software  development  plan,  standards,  and 
procedures.  (L2-65,  A3) 

□  The  SQA  group  provides  consultation  and  review  of  the 
plans,  standards,  and  procedures  with  regard  to: 

□  compliance  to  organizational  policy, 

□  compliance  to  externally  imposed  standards  and 
requirements  (e.g.,  standards  required  by  the 
statement  of  work), 

□  standards  that  are  appropriate  for  use  by  the  project, 

□  topics  that  should  be  addressed  in  the  software 
development  plan,  and 

□  other  areas  as  assigned  by  the  project. 

□  The  SQA  group  verifies  that  plans,  standards,  and 
procedures  are  in  place  and  can  be  used  to  review  and 
audit  the  software  project. 

The  SQA  group  reviews  the  software  engineering  activities 
to  verify  compliance.  (L2-66,  A4) 

The  software  engineering  activities  are  evaluated  against  the 
software  development  plan  and  the  designated  software 
standards  and  procedures.  (L2-66,  A4,  1) 

The  SQA  group  audits  designated  software  work  products 
to  verify  compliance.  (L2-56.  A5) 

□  The  deliverable  software  products  are  evaluated  before 
they  are  delivered  to  the  customer. 

□  The  software  work  products  are  evaluated  against  the 
designated  software  standards,  procedures,  and 
contractual  requirements. 

The  SQA  group  conducts  periodic  reviews  of  its  activities 
and  findings  with  the  customer's  SQA  personnel,  as 
appropriate.  (L2-67,  A8) 

The  SQA  activities  are  reviewed  with  senior  management  on 
a  periodic  basis.  (L2-68,  VI) 

The  SQA  activities  are  reviewed  with  the  project  manager 
on  a  periodic  and  event-driven  basis.  (L2-69,  V2) 

Experts  independent  of  the  SQA  group  periodically  review 
the  activities  and  software  work  products  of  the  project's 

SQA  group.  (L2-69,  V3) 
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SQA  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  quality 
assurance  process. 


Review  or  Audit 

Review 

Participants 

References 

Senior  management  periodically  reviews 
the  SQA  activities  and  results.  (L2-61,  Cl, 

3) 

Senior 

management 

The  SQA  plan  is  reviewed  by  the  affected 
groups  and  individuals.  (L2-63,  Al,  2) 

Affected 

groups 

Affected 

individuals 

The  SQA  group  participates  in  the 
preparation  and  review  of  the  project's 
software  development  plan,  standards,  and 
procedures.  (L2-65,  A3) 

SQA  group 

The  SQA  group  provides  consultation  and 

review  of  the  plans,  standards,  and 

procedures  with  regard  to;  (L2-66,  A3,  1 ) 

□  compliance  to  organizational  policy, 

□  compliance  to  externally  imposed 
standards  and  requirements  (e.g., 
standards  required  by  the  statement  of 
work), 

□  standards  that  are  appropriate  for  use 
by  the  project, 

□  topics  that  should  be  addressed  in  the 
software  development  plan,  and 

□  other  areas  as  assigned  by  the  project. 

SQA  group 

The  SQA  group  reviews  the  software 
engineering  activities  to  verify  compliance. 
(L2-66,  A4) 

SQA  group 

The  SQA  group  audits  designated  software 
work  products  to  verify  compliance.  (L2- 
66,  A5) 

SQA  group 

The  SQA  group  conducts  periodic  reviews 
of  its  activities  and  findings  with  the 
customer's  SQA  personnel,  as  appropriate. 
(L2-67.  A8) 

SQA  group 

Customer's 

SQA 

personnel 

The  SQA  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2-68, 
VI) 

Senior 

management 

Continued  on  next  page 
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SQA  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  quality 
assurance  process,  continued  from  the  previous  page. 


V 

Review  «r  Audit 

Review 

Participants 

References 

The  SQA  activities  are  reviewed  with  the 
project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-69,  V2) 

Project 

manager 

Experts  independent  of  the  SQA  group 
periodically  review  the  activities  and 
software  work  products  of  the  project’s 

SQA  group.  (L2-69,  V3) 

Experts 
independent  of 
the  SQA 
group 

SQA  group 
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SQA  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  mai  'iged  and 
controlled  during  the  software  quality  assurance  process. 


V 

Work  Products  Managed  and  Controlled 

References 

SQA  plan.  (L2-64,  Al,  3) 

Documentation  of  noncompliance  items.  (L2-67,  A7,  4) 
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SQA  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software  quality 
assurance  process. 


Measurements 

References 

Measurements  are  made  and  used  to  determine  the  cost  and 

schedule  status  of  SQA  activities.  (L2-68,  Ml) 

Examples  of  measurements  include; 

□  Completions  of  milestones  for  the  SQA  activities 
compared  to  the  plan. 

□  Work  completed,  effort  expended,  and  funds  expended 
in  the  SQA  activities  compared  to  the  plan. 

□  Numbers  of  product  audits  and  activity  reviews 
compared  to  the  plan. 
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SQA  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  software  quality  assurance  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


V 

Documented  procedures 

References 

A  SQA  plan  is  prepared  for  the  software  project  according 
to  a  documented  procedure.  (L2-63,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Deviations  identified  in  the  software  activities  and  software 
work  products  are  documented  and  handled  according  to  a 
documented  procedure.  (L2-67,  A7) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 
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SQA  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  quality  assurance 
process. 


Training 

References 

Members  of  the  SQA  group  are  trained  to  perform  their 
SQA  activities.  (L2-62,  Ab3) 

The  members  of  the  software  project  receive  orientation  on 
the  role,  responsibilities,  authority,  and  value  of  the  SQA 
group.  (L2-63,  Ab4) 

L2-Process-152 


CMU/SEi-94>HB-1 


SQA  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  software  quality  assurance 
process. 


Tools 

References 

1 

Tools  to  support  the  SQA  activities.  (L2-62,  Ab2,  3) 
Examples  of  support  tools  include: 

□  workstations, 

□  database  programs, 

□  spreadsheet  programs,  and 

□  auditing  tools. 
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Software  Configuration  Management  (SCM)  Process 
SCM  Process  -  Overview 


SCM  process 
purpose 


SCM  process 
description 


The  purpose  of  Software  Configuration  Management  is  to  establish  and  maintain 
the  integrity  of  the  products  of  the  software  project  throughout  the  project's 
software  life  cycle.  (L2-71) 


Software  Configuration  Management  involves  identifying  the  configuration  of  the 
software  (i.e.,  selected  software  work  products  and  their  descriptions)  at  given 
points  in  time,  systematically  controlling  changes  to  the  configuration,  and 
maintaining  the  integiity  and  traceability  of  the  configuration  throughout  the 
software  life  cycle.  The  work  products  placed  under  software  configuration 
management  include  the  software  products  that  are  delivered  to  the  customer  (e.g., 
the  software  requirements  document  and  the  code)  and  the  items  that  are  identified 
with  or  required  to  create  these  software  products  (e.g.,  the  compiler). 

A  software  baseline  library  is  established  containing  the  software  baselines  as  they 
are  developed.  Changes  to  baselines  and  the  release  of  software  products  built 
from  the  software  baseline  library  are  systematically  controlled  via  the  change 
control  and  configuration  auditing  functions  of  software  configuration 
management. 

This  key  process  area  covers  the  practices  for  performing  the  software 
configuration  management  function.  The  practice .  identifying  specific 
configuration  items/units  are  contained  in  the  key  process  areas  that  describe  the 
development  and  maintenance  of  each  configuration  item/unit.  (L2-71) 


Continued  on  next  page 
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SCM  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L2-Process-157 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L2-Process-161 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L2-Process-162 

Activities 

Description  of  the  activities  of  the 
process. 

L2-Process-163 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L2-Process-165 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L2-Process-166 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L2-Proce.ss-172 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L2-Process-]74 

Measurements 

Description  of  process  measurements. 

L2-Process-175 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L2-Process-176 

Training 

List  of  training. 

L2-Process-177 

Tools 

List  of  tools. 

L2-Process-178 
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SCM  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process. 


Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

□  The  SCM  plan  is  reviewed  by  the 
affected  groups. 

□  The  configuration  management  library 
system  provides  for  the  sharing  and 
transfer  of  configmation  items/units 
between  the  affected  groups  and 
between  control  levels  within  the 
library.  (L2-78,  A3,  3) 

□  Standard  reports  documenting  the  SCM 
activities  and  the  contents  of  the 
software  baseline  are  developed  and 
made  available  to  affected  groups  and 
individuals.  (L2-81,  A9) 

Affected 

individuals 

Standard  reports  documenting  the  SCM 
activities  and  the  contents  of  the  software 
baseline  are  developed  and  made  available 
to  affected  groups  and  individuals.  (L2- 
81,  A9) 

Manager 

A  manager  is  assigned  specific 
responsibilities  for  SCM.  (L2'75,  Ab3,  1) 

Person 

responsible  for 
each 

configuration 

unit/item 

The  person  responsible  for  each 
configuration  item/unit  (i.e.,  the  owner, 
from  a  configuration  management  point  of 
view)  is  identified.  (L2-79,  A4,  6) 

Project 

manager 

The  SCM  activities  are  reviewed  with  the 
project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-83,  V2) 

Project 

software 

manager 

The  results  of  software  baseline  audits  are 
reported  to  the  project  software  manager. 
(L2-82,  A 10,  6) 

Senior 

management 

The  SCM  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2-82, 

vn 

Continued  on  next  page 
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SCM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 
configuration 
control  board 
(SCCB) 

□  A  board  having  the  authority  for 
n  anaging  the  project’s  software 
baselines  (i.e.,  a  software  configuration 
control  board  -  SCCB)  exists  or  is 
established.  (L2-73,  Abl) 

The  SCCB; 

□  Authorizes  the  establishment  of 
software  baselines  and  the 
identification  of  configuration 
items/units. 

□  Represents  the  interests  of  the 
project  manager  and  all  groups 
who  may  be  affected  by  changes  to 
the  software  baselines. 

□  Reviews  and  authorizes  changes  to 
the  software  baselines. 

□  Authorizes  the  creation  of  products 
from  the  software  baseline  library. 

□  Only  configuration  items/units  that  are 
approved  by  the  SCCB  are  entered  into 
the  software  baseline  library.  (L2-80, 
A6.  2) 

Continued  on  next  page 
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SCM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software 
configuration 
management 
(SCM)  group 

□  A  group  that  is  responsible  for 
coordinating  and  implementing  SCM 
for  the  project  (i.e.,  the  SCM  group) 
exists.  (L2-74,  Ab2) 

The  SCM  group  coordinates  or 
implements; 

□  Creation  and  management  of  the 
project's  software  baseline  library. 

□  Development,  maintenance,  and 
distribution  of  the  SCM  plans, 
standards,  and  procedures. 

□  The  identification  of  the  set  of 
work  products  to  be  placed  under 
SCM. 

□  Management  of  the  access  to  the 
software  baseline  library. 

□  Updates  of  the  software  baselines. 

□  Creation  of  products  from  the 
software  baseline  library. 

□  Recording  of  SCM  actions. 

□  Production  and  distribution  of 

SCM  reports. 

□  Members  of  the  SCM  group  are 
trained  in  the  objectives,  procedures, 
and  methods  for  performing  their  SCM 
activities.  {L2-76,  Ab4) 

□  The  SCM  group  periodically  audits 
software  baselines  to  verify  that  they 
conform  to  the  documentation  that 
defines  them.  (L2-83,  V3) 

Software 

engineering 

group 

Members  of  the  .software  engineering 
group  and  other  softv/are-related  groups 
are  trained  to  perform  their  SCM  activities. 
(L2-76,  Ab5) 

Continued  on  next  page 
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SCM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  configuration  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software- 
related  groups 

□  Members  of  the  software  engineering 
group  and  other  software-related 
groups  are  trained  to  perform  their 

SCM  activities.  (L2-76,  Ab5) 

□  The  SCM  plan  covers  the  SCM 
requirements  and  activities  to  be 
performed  by  the  software  engineering 
group  and  other  software-related 
groups.  (L2-77,  A2,  2) 

SQA  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  SCM  and  reports  the  results. 
(L2-83,  V4) 
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SCM  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  software  configuration  management  process. 


V 

Input 

State 

References 

Change  requests  for 

configuration 

items/units 

are  initiated  according  to  a 
documented  procedure.  (L2-79,  A5) 

Problem  reports  for 

configuration 

items/units 

are  initiated  according  to  a 
documented  procedure.  (L2-79,  A5) 

SCM  plan 

□  ic  documented.  (L2-77,  A2) 

□  is  approved.  (L2-77,  A2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  configuration  management  process.. 


Condition 

References 

The  project  follows  a  written  organizational  policy  for 
implementing  software  configuration  management  (SCM). 
(L.2-72.  Cl) 

[Refer  to  Level  2  Policies  for  additional  information 
regarding  SCM  policy.] 

Responsibility  for  SCM  for  each  project  is  explicitly 
assigned.  (L2-72,  Cl,l) 

A  board  having  the  authority  for  managing  the  project’s 
software  baselines  (i.e.,  a  software  configuration  control 
board  -  SCCB)  exists  or  is  established.  (L2-73,  Abl) 

A  group  that  is  responsible  for  coordinating  and 
implementing  SCM  for  the  project  (i.e.,  the  SCM  group) 
exists.  (L2-74,  Ab2) 

Adequate  resources  and  funding  are  provided  for 
performing  the  SCM  activities.  (L2-75,  Ab3) 

A  manager  is  assigned  specific  responsibilities  for  SCM. 
(L2-75,  Ab3,  1) 

Tools  to  support  the  SCM  activities  are  made  available.  (L2- 
75,  Ab3,  2) 

Members  of  the  SCM  group  are  trained  in  the  objectives, 
procedures,  and  methods  for  performing  their  SCM 
activities.  (L2-76,  Ab4) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  are  trained  to  perform  their  SCM 
activities.  (L2-76,  Ab5) 
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SCM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  configuration 
management  pro -ess. 


Input 

Org.  Input 

References 

Change  requests  for  configuration 
items/units.  (L2-79,  A5) 

Changes  to  baselines.  (L2-80,  A6) 

Configuration  items/units.  (L2-78,  A3,  2) 

Designated  internal  software  work 
products.  (L2-72,  Cl,  3) 

Designated  support  tools  used  inside  the 
project.  (L2-72,  Cl,  3) 

Externally  deliverable  software  products. 
(L2-72,  Cl,  3) 

Problem  reports  for  configuration 
items/units.  (L2-79,  A5) 

SCM  plan.  (L2-77,  A2) 

[Refer  to  Level  2  Standards  for  additional 
information  regarding  a  SCM  plan.] 

Software  baselines.  (L2-73,  Cl,5) 

Software  work  products.  (L2-78,  A4) 

Updates  of  the  software  baselines.  {L2-75, 
Ab2,  5) 

Work  products  to  be  placed  under  SCM. 
(L2-75,  Ab2,  3) 
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SCM  Process  -  Activities 


Act!  /ities 


The  table  below  lists  the  recommended  activities  for  the  software  configuration 
management  process. 


V 

Activities 

References 

A  SCM  plan  is  prepared  for  each  software  project  according 
to  a  documented  procedure.  (L2-76,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

A  documented  and  approved  SCM  plan  is  used  as  the  basis 
for  performing  the  SCM  activities.  (L2-77,  A2) 

A  configuration  management  library  system  is  established  as 
a  repository  for  the  software  baselines.  (L2-77,  A3) 

[Refer  to  SCM  Process  Tools  for  additional  information 
regarding  a  configuration  management  library  system.] 

The  software  work  products  to  be  placed  under 

configuration  management  are  identified.  (L2-78,  A4) 

□  The  configuration  items/units  are  selected  based  on 
documented  criteria. 

□  The  configuration  items/units  are  assigned  unique 
identifiers. 

□  The  characteristics  of  each  configuration  item/unit  are 
specified. 

□  The  software  baselines  to  which  each  configuration 
item/unit  belongs  are  specified. 

□  The  point  in  its  development  that  each  configuration 
item/unit  is  placed  under  configuration  management  is 
specified. 

□  The  person  responsible  for  each  configuration  item/unit 
(i.e.,  the  owner,  from  a  configuration  management  point 
of  view)  is  identified. 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

Changes  to  baselines  are  controlled  according  to  a 
documented  procedure.  (L2-80,  A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 
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Continued  on  next  page 


CMU/SEI-94-HB-1 


L2-Process-163 


SCM  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  configuration 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

Products  from  the  software  baseline  library  are  created  and 
their  release  is  controlled  according  to  a  documented 
procedure.  (L2-80,  A7,) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  status  of  configuration  items/units  is  recorded  according 
to  a  documented  procedure.  (L2-80,  A8) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Standard  reports  documenting  the  SCM  activities  and  the 
contents  of  the  software  baseline  are  developed  and  made 
available  to  affected  groups  and  individuals.  (L2-81 ,  A9) 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Measurements  are  made  and  used  to  determine  the  status  of 
the  SCM  activities.  (L2-82,  Ml) 

The  SCM  activities  arc  reviewed  with  senior  management  on 
a  periodic  basis.,  (L2-82,  VI) 

The  SCM  activities  <  'e  reviewed  with  the  project  manager 
on  both  a  periodic  and  event-driven  basis.  (L2-83,  V2) 

The  SCM  group  periodically  audits  software  baselines  to 
verify  that  they  conform  to  the  documentation  that  defines 
them.  (L2-83,  V3) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  SCM  and  reports  the 
results.  (L2-83,  V4) 

[Refer  to  SCM  Process  Reviews  and  Audits  for  additional 
information.] 

L2-Process-164 


CMU/SEI-94  HB-1 


SCM  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  software 
configuration  management  process. 


V 

Output 

Org.  Output 

References 

Action  items  from  the  software  baseline 
audit.  (L2-82,  AIO,  7) 

Archive  versions  of  configuration 
items/units.  (L2-78,  A3,  5) 

Changes  to  the  software  baselines.  (L2-74, 
Abl,  3) 

Configuration  items/units.  (L2-73,  Abl,  1) 

Current  status  and  history  (i.e.,  changes 
and  other  actions)  of  each  configuration 
item/unit.  (L2-81,  A8,  2) 

Measurements  (to  determine  the  status  of 
the  SCM  activities).  (L2-82,  Ml) 

Products  from  the  software  baseline 
library.  (L2-74,  Abl,  4) 

Project's  software  baseline  library  (or 
repository).  (L2-75,  Ab2,  1) 

Results  of  the  software  baseline  audit.  (L2- 
82,  AIO,  6) 

Results  of  SQA  group  reviews  and/or 
audits  of  the  activities  and  work  products 
for  SCM.  (L2-83,  V4) 

SCM  plan.  (L2-75,  Ab2,  2) 

SCM  procedures.  (L2-75,  Ab2,  2) 

SCM  records.  (L2-72,  Cl,4) 

SCM  reports.  (L2-75,  Ab2,  8) 

SCM  standards.  (L2-75,  Ab2,  2) 

Software  baselines.  (L2-73,  Abl) 

Standard  reports  documenting  the  SCM 
activities  and  the  contents  of  the  software 
baseline.  (L2-81,  A9) 

Work  products  to  be  placed  under  SCM. 
(L2-75,  Ab2,  3) 
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SCM  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  managCinent  process. 


V 

Output 

State 

References 

Action  items  from 
the  software  baseline 
audit 

are  tracked  to  closure.  (L2-82,  A 10. 
7) 

Changes  to  the 
software  baselines 

□  are  reviewed  by  the  SCCB.  (L2- 
74,  Abl,  3) 

□  are  authorized  by  the  SCCB. 
(L2-74,  Abl.  3) 

□  are  controlled  according  to  a 
documented  procedure.  (L2-80, 
A6) 

Configuration 

items/units 

□  identification  is  authorized  by 
the  SCCB.  (L2-73,  Abl,  1) 

□  are  selected  based  on 
documented  criteria.  (L2-79, 

A4,  1) 

□  are  assigned  unique  identifiers. 
(L2-79,  A4,  2) 

□  characteristics  are  specified. 
(L2-79,  A4,  3) 

□  are  checked  in  and  out  in  a 
manner  that  maintains  the 
correctness  and  integrity  of  the 
software  baseline  library.  (L2- 
80,  A6,  3) 

□  current  status  and  history  (i.e., 
changes  and  other  actions)  are 
maintained.  (L2-81,A8.  2) 

Configuration 
item’s/unit’s  history 
(i.e.,  changes  and 
other  actions) 

is  maintained.  (L2-81,A8,  2) 

Configuration 
item’s/unit's  status 

□  is  recorded  according  to  a 
documented  procedure.  (L2-80, 
A8) 

□  is  maintained.  (L2-81,  A8,  2) 

Measurements  (to 
determine  the  status 
of  the  SCM  activities) 

□  are  made.  (L2-82,  Ml) 

□  are  used.  (L2-82,  Ml) 
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SCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

Products  from  the 
software  baseline 
library 

□  are  authorized  to  be  created  by 
theSCCB.  (L2-74,  Abl,  4) 

□  creation  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  6) 

□  are  created  and  their  release  is 
controlled  according  to  a 
documented  procedure.  (L2-80, 
A7) 

□  for  both  internal  and  external 
use,  are  built  only  from 
configuration  items/units  in  the 
software  baseline  library.  (L2- 
80,  A7,  2) 

Project's  software 
baseline  library  (or 
repository) 

□  is  established  or  is  accessible  to 
the  projects  for  storing 
configuration  items/units  and  the 
associated  SCM  records.  (L2-72, 
Cl,  4) 

□  creation  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-.’5,  Ab2,  I) 

□  management  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  1) 

□  access  management  is 
coordinated  or  implemented  by 
the  SCM  group.  (L2-75,  Ab2, 

4) 

□  completeness  of  contents  is 
verified.  (L2-81,  A 10,  4) 

□  correctness  of  contents  is 
verified.  (L2-81,  AlO,  4) 

Results  of  the 
software  baseline 
audit 

are  reported  to  the  project  software 
manager.  (L2-82,  AlO,  6) 

Continued  on  next  page 
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SCM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


V 

Output 

State 

References 

Results  of  SQA 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  SCM 

are  reported.  (L2-83,  V4) 

SCM  plan 

□  development  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75.  Ab2,  2) 

□  maintenance  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  is  prepared  for  each  software 
project  according  to  a 
documented  procedure.  (L2-76 
A!) 

□  is  developed  in  the  early  stages 
of,  and  in  parallel  with,  overall 
project  planning.  (L2-76,  A  I,  I) 

□  is  reviewed  by  the  affected 
groups.  (L2-77,  Al,2) 

□  is  managed  and  controlled.  (L2- 
77,  A1,3) 

□  is  documented.  (L2-77,  A2) 

□  is  approved,  (L2-77,  A2) 

□  is  used  as  the  basis  for 
performing  the  SCM  activities. 
(L2-77,  A2) 

SCM  procedures 

□  development  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75.  Ab2,  2) 

□  maintenance  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

Continued  on  next  page 
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SCM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


Output 

State 

References 

SCM  reports 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2;  8) 

□  production  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  8) 

SCM  standards 

□  development  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  distribution  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

□  maintenance  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  2) 

Software  baselines 

□  are  authorized  to  be  established 
by  theSCCB.  (L2-73,  Abl,  1) 

□  updates  are  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75,  Ab2,  5) 

□  to  which  each  configuration 
item/unit  belongs  are  specified. 
(L2-79,  A4,  4) 

□  integrity  is  assessed.  (L2-81, 

AlO,  2) 

Standard  reports 
documenting  the 

SCM  activities 

□  are  developed.  (L2-81,  A9j 

□  are  made  available  to  affected 
groups  and  individuals.  (L2-81, 
A9) 

Standard  reports 
documenting  the 
contents  of  the 
software  baseline 

□  are  developed.  (L2-81,  A9) 

□  are  made  available  to  affected 
groups  and  individuals.  (L2-81, 
A9) 

Work  products  to  be 
placed  under  SCM 

□  identification  is  coordinated  or 
implemented  by  the  SCM  group. 
(L2-75.  Ab2,  3) 

□  are  identified.  {L2-78,  A4) 
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SCM  Process  -  Exit  Criteria,  continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  configuration  management  process. 


V 

Condition 

References 

SCM  is  implemented  throughout  the  project’s  life  cycle. 
(L2-72,  Cl,  2) 

SCM  is  implemented  for  externally  deliverable  software 
products,  designated  internal  software  work  products,  and 
designated  support  tools  used  inside  the  project  (e.g., 
compilers).  (L272,  Cl,  3) 

The  SCM  group  coordinates  or  implements  the  recording  of 
SCM  actions.  (L2-75,  Ab2,  7) 

A  configuration  management  library  system  is  established  as 
a  repository  for  the  software  baselines.  (L2-77,  A3) 

The  point  in  its  development  that  each  configuration 
item/unit  is  placed  under  configuration  management  is 
specified.,  (L2-79,  A4,  5) 

The  person  responsible  for  each  configuration  item/unit  (i.e., 
the  owner,  from  a  configuration  management  point  of  view) 
is  identified.  (L2-79,  A4,  6) 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

Reviews  and/or  regression  tests  are  performed  to  ensure  that 
changes  have  not  caused  unintended  effects  on  the  baseline. 
(L2-80,  A6,  1) 

Only  configuration  items/units  that  are  approved  by  the 
SCCB  are  entered  into  the  software  baseline  library.  (L2-80, 
A6,  2) 

The  configuration  management  actions  are  recorded  in 
sufficient  detail  so  that  the  content  and  status  of  each 
configuration  item/unit  are  known  and  previous  versions  can 
be  recovered.  (L2-81,  A8,  1) 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10) 

The  SCM  activities  are  reviewed  with  senior  management  on 
a  periodic  basis.  (L2-82,  VI) 

The  SCM  activities  are  reviewed  with  the  project  manager 
on  both  a  periodic  and  event-driven  basis.  (L2-83,  V2) 

C mu  lin'd  on  next  page 
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SCM  Process  -  Exit  Criteria.  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  configuration  management  process,  continued  from  the 
previous  page. 


V 

Condition 

References 

The  SCM  group  periodically  audits  software  baselines  to 
verify  that  they  conform  to  the  documentation  that  defines 
them.  (L2-83,  V3) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  SCM  and  reports  the 
results.  (L2-83,  V4) 
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SCM  Process  >  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
configuration  management  process. 


Review  or  Audit 

Review 

Participants 

References 

The  software  baselines  and  SCM  activities 
are  audited  on  a  periodic  basis.  (L2-73, 

Cl.  5) 

Not  specified  in 
CMM 

The  SCCB  reviews  and  authorizes  changes 
to  the  software  baselines.  (L2-74,  Abl,  3) 

SCCB 

The  SCM  plan  is  reviewed  by  the  affected 
groups.  (L2-77,  Al,  2) 

Affected 

groups 

Change  requests  and  problem  reports  for 
all  configuration  items/units  are  initiated, 
recorded,  reviewed,  approved,  and  tracked 
according  to  a  documented  procedure. 
(L2-79,  A5) 

Not  specified  in 
CMM 

Reviews  and/or  regression  tests  are 
performed  to  ensure  that  changes  have  not 
caused  unintended  effects  on  the  baseline. 
(L2-80.  A6,  I) 

Not  specified  in 
CMM 

Software  baseline  audits  are  conducted 
according  to  a  documented  procedure. 
(L2-81.  A 10) 

Not  specified  in 
CMM 

The  SCM  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2-82, 
VI) 

Senior 

management 

The  SCM  activities  are  reviewed  with  the 
project  manager  on  both  a  periodic  and 
event-driven  basis.  (L2-83,  V2) 

Project 

manager 

The  SCM  group  periodically  audits 
software  baselines  to  verify  that  they 
conform  to  the  documentation  that  defines 
them.  (L2-83,  V3) 

SCM  group 

Continued  on  next  page 
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SCM  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software 
configuration  management  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  SCM  and  reports  the  results. 
(L2-83,  V4) 

At  a  minimum,  the  reviews  and/or  audits 
verify; 

□  Compliance  with  the  SCM  standards 
and  procedures  by: 

□  the  SCM  group, 

□  theSCCB, 

□  the  software  engineering  group, 
and 

□  other  software>related  groups. 

□  Occurrence  of  periodic  baseline  audits. 

SQA  group 
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SCM  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  managed  and 
controlled  during  the  configuration  management  process. 


Work  Products  Managed  and  Controlled 

References 

SCM  plan.  (L2-77,  Al,3) 
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SCM  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software 
configuration  management  process. 


V 

Measurements 

References 

Measurements  are  made  and  used  to  determine  the  status  of 
the  SCM  activities.  (L2-82,  Ml) 

Examples  of  measurements  include: 

□  Number  of  change  requests  processed  per  unit  time. 

□  Completions  of  milestones  for  the  SCM  activities 
compared  to  the  plan. 

□  Work  completed,  effort  expended,  and  funds  expended 
in  the  SCM  activities. 

CMU/SEI-94-HB-1 


L2-Process-175 


SCM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  software  configuration  management 
process  recommended  to  be  performed  according  to  a  documented  procedure. 


Documented  procedures 

References 

A  SCM  plan  is  prepared  for  each  software  project  according 
to  a  documented  procedure.  (L2-76,  Al) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

» 

Changes  to  baselines  are  controlled  according  to  a 
documented  procedure.  (L2-80,  A6) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Products  from  the  software  baseline  library  are  created  and 
their  release  is  controlled  according  to  a  documented 
procedure.  (L2-80,  A7) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

The  status  of  configuration  items/units  is  recorded  according 
to  a  documented  procedure.  (L2-80,  A8) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information.] 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10) 

[Refer  to  Level  2  Procedure  Checklists  for  additional 
information] 
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SCM  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  configuration 
management  process. 


V 

Training 

References 

Members  of  the  SCM  group  are  trained  in  the  objectives, 
procedures,  and  methods  for  performing  their  SCM 
activities.  (L2-76,  Ab4) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  are  trained  to  perform  their  SCM 
activities.  (L2-76,  Ab5) 

CMU/SEI-94-HB-1 


L2-Process-177 


SCM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  software  configuration 
management  process. 


Tools 

References 

Tools  to  support  the  SCM  activities.  (L2-75,  Ab3,  2) 
Examples  of  support  tools  include: 

□  workstations, 

□  database  programs,  and 

□  configuration  management  tools. 

A  configuration  management  library  system  is  established  as 

a  repository  for  the  software  baselines.  (L2-77,  A3) 

This  library  system: 

□  Supports  multiple  control  levels  of  SCM. 

□  Provides  for  the  storage  and  retrieval  of  configuration 
items/units. 

□  Provides  for  the  sharing  and  transfer  of  configuration 
items/units  between  the  anected  groups  and  between 
control  levels  within  the  library, 

□  Helps  in  the  use  of  product  standards  for  configuration 
items/units. 

□  Provides  for  the  storage  and  recovery  of  archive  versions 
of  configuration  items/units. 

□  Helps  to  ensure  correct  creation  of  products  from 
software  baseline  library. 

□  Provides  for  the  storage,  update,  and  retrieval  of  SCM 
records. 

□  Supports  production  of  SCM  reports, 

□  Provides  for  the  maintenance  of  the  library  structure  and 
contents. 
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Level  2  Procedure  Checklists 
Overview 


Introduction 


Purpose 


In  this  section 


This  section  describes  all  the  explicit  documented  piocedures  recommended  in  the 
Capability  Maturity  Model  for  maturity  level  2. 


The  purpose  of  the  procedure  checklists  is  to  provide: 

•  Guidance  in  identifying  which  procedures  are  recommended  by  the  CMM  at 
level  2. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  procedures  to 
determine  if  those  procedures  are  consistent  with  the  CMM  at  level  2. 

•  Information  that  can  be  used  to  develop  software  procedures  that  are  consistent 
with  the  CMM  at  level  2. 


This  section  covers  the  following  documented  procedures: 


CMM  Level  2  Procedures 

See  Page 

Requirements  management  procedures 

L2-Procedures-2 

Software  project  planning  procedures 

L2-Procedures-3 

Software  project  tracking  &  oversight  procedures 

L2-Procedures-6 

Software  subcontract  management  procedures 

L2-Proc5dures-7 

Software  quality  assurance  procedures 

L2-Procedures-l  1 

Software  configuration  management  procedures 

L2-Procedures-12 
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Requirements  Management  (RM)  Procedures 


Documented 

procedures 


There  are  no  recommended  documented  procedures  for  the  requirements 
management  process. 
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Software 


Documented 

procedures 


Project  Planning  (SPP)  Procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
project  planning  process. 


4 

Documented  Procedures 

References 

Software  project  commitments  made  to  individuals  and 
groups  external  to  the  organization  are  reviewed  with  senior 
management  according  to  a  documented  procedure.  (L2- 
17.  A4) 

The  project's  software  development  plan  is  developed 
according  to  a  documented  procedure.  (L2-18,  A6) 

This  procedure  typically  specifies  that: 

□  The  software  development  plan  is  based  on  and 
conforms  to: 

□  the  customer's  standards,  as  appropriate: 

□  the  project's  standards; 

□  the  approved  statement  of  work;  and 

□  the  allocated  requirements. 

□  Plans  for  software-related  groups  and  other 
engineering  groups  involv^  in  the  activities  of  the 
software  engineering  group  are  negotiated  with  those 
groups,  the  support  efforts  are  budgeted,  and  the 
agreements  are  documented. 

□  Plans  for  involvement  of  the  software  engineering 
group  in  the  activities  of  other  software-related  groups 
and  other  engineering  groups  are  negotiated  with  those 
groups,  the  support  efforts  are  budgeted,  and  the 
agreements  are  documented. 

□  The  software  development  plan  is  reviewed  by: 

□  the  project  manager, 

□  the  project  software  manager, 

□  the  other  software  managers,  and 

□  other  affected  groups. 

□  The  software  development  plan  is  managed  and 
controlled. 

Continued  on  next  page 
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Software  Project  Planning  (SPP)  Procedures,  Continued 


Documented  The  table  below  lists  the  recommended  documented  procedures  for  the  software 

procedures,  project  planning  process,  continued  from  the  previous  page. 

continued 


T 

Documented  Procedures 

References 

Estimates  for  the  size  of  the  software  woiic  products  (or 
changes  to  the  size  of  software  work  products)  are  derived 
according  to  a  documented  procedure.  (L2-21,  A9) 

This  procedure  typically  specifies  that: 

□  Size  estimates  are  made  for  all  major  software  work 
products  and  activities. 

□  Software  work  products  arc  decomposed  to  the 
granularity  needed  to  meet  the  estimating  objectives. 

□  Historical  daia  are  used  where  available. 

□  Size  estimating  assumptions  are  documented. 

□  Size  estimates  are  documented,  reviewed,  and  agreed  to. 

Estimates  for  the  software  project's  effort  and  costs  are 
derived  according  to  a  documented  procedure.  (L2-22, 

AlO) 

This  procedure  typically  specifies  that: 

□  Estimates  for  the  software  project’s  effort  and  costs  are 
related  to  the  size  estimates  of  the  software  woik 
products  (or  the  size  of  the  changes). 

□  Productivity  data  (historical  and/or  current)  are  used  for 
the  estimates  when  available;  sources  and  rationale  for 
these  data  are  documented. 

□  The  productivity  and  cost  data  are  from  the 
organization's  projects  when  possible. 

□  The  productivity  and  cost  data  take  into  account  the 
effort  and  significant  costs  that  go  into  making  the 
software  work  products. 

□  Effort,  staffing,  and  cost  estimates  are  based  on  past 
experience. 

□  Similar  projects  should  be  used  when  possible. 

□  Time  phasing  of  activities  is  derived. 

□  Distributions  of  the  effort,  staffing,  and  cost 
estimates  over  the  software  life  cycle  are  prepared. 

□  Estimates  and  the  assumptions  made  in  deriving  the 
estimates  are  documented,  reviewed,  and  agreed  to. 

Continued  on  next  page 
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Software  Project  Planning  (SPP)  Procedures,  continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
project  planning  process,  continued  from  the  previous  page. 


T 

Documented  Procedures 

References 

Estimates  for  the  project's  critical  computer  resources  are 
derived  according  to  a  documented  procedure.  (L2-23, 

All) 

This  procedure  typically  specifies  that: 

□  Critical  computer  resources  for  the  project  are  identified. 

□  Estimates  for  the  critical  computer  resources  are  related 
to  the  estimates  of: 

□  The  size  of  the  software  work  products. 

□  The  operational  processing  load. 

□  The  communications  traffic. 

□  Estimates  of  the  critical  computer  resources  are 
documented,  reviewed,  and  agreed  to. 

The  project's  software  schedule  is  derived  according  to  a 
documented  procedure.  (L2-23,  A12) 

This  procedure  typically  specifics  that: 

□  The  software  schedule  is  related  to: 

□  The  size  estimate  of  the  software  work  products  (or 
the  size  of  changes). 

□  The  software  effort  and  costs. 

□  The  software  schedule  is  based  on  past  experience. 

□  Similar  projects  are  used  when  possible.. 

□  The  software  schedule  accommodates  the  imposed 
milestone  dates,  critical  dependency  dates,  and  other 
constraints. 

□  The  software  schedule  activities  are  of  appropriate 
duration  and  the  milestones  are  of  appropriate  time 
separation  to  support  accuracy  in  progress  measurement. 

□  Assumptions  made  in  deriving  the  schedule  are 
documented. 

□  The  software  schedule  is  documented,  reviewed,  and 
agreed  to. 

CMU/SEI-94'HB-1 


L2-Procedures-5 


Software  Project  Tracking  &  Oversight  (SPTO)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
project  tracking  and  oversight  process. 


~T 

Documented  Procedures 

References 

The  project's  software  development  plan  is  revised  according 

to  a  documented  procedure.  (L2-33,  A2) 

This  procedure  typically  specifies  that: 

□  The  software  development  plan  is  revised,  as  appropriate, 
to  incorporate  plan  refinements  and  incorporate  plan 
changes,  particularly  when  plans  change  significantly. 

□  The  software  development  plan  is  updated  to  incorporate 
all  new  software  project  commitments  and  changes  to 
commitments. 

□  The  software  development  plan  is  reviewed  at  each 
revision. 

□  The  software  development  plan  is  managed  and 
controlled. 

Software  project  commitments  and  changes  to  commitments 
made  to  individuals  and  groups  external  to  the  organization 
are  reviewed  with  senior  management  according  to  a 
documented  procedure.  (L2-35,  A3) 

Foraial  reviews  to  address  the  accomplishments  and  results 
of  the  software  project  are  conducted  at  selected  project 
milestones  according  to  a  documented  procedure.  G-2-39.. 
A13) 
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Software  Subcontract  Management  (SSM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process. 


Documented  Procedures 

The  work  to  be  subcontracted  is  defined  and  planned  according  to  a 
documented  procedure.  (L2-47,  Al) 

This  procedure  typically  specifies  that: 

□  The  software  products  and  activities  to  be  subcontracted  are  selected 
based  on  a  balanced  assessment  of  both  technical  and  nontechnical 
characteristics  of  the  project. 

□  The  functions  or  subsystems  to  be  subcontracted  are  selected  to 
match  the  skills  and  capabilities  of  potential  subcontractors. 

□  The  specification  of  the  software  products  and  activities  to  be 
subcontracted  is  determined  based  on  a  systematic  analysis  and 
appropriate  partitioning  of  the  system  and  software 
requirements. 

□  The  specification  of  the  work  to  be  subcontracted  and  the  standards 
and  procedures  to  be  followed  are  derived  from  the  project's: 

□  statement  of  work, 

□  system  requirements  allocated  to  software, 

□  software  requirements, 

□  software  development  plan,  and 

□  software  standards  and  procedures. 

□  A  subcontract  statement  of  work  is: 

□  prepared, 

□  reviewed, 

□  agreed  to, 

□  revised  when  necessary,  and 

□  managed  and  controlled. 

□  A  plan  for  selecting  a  subcontractor  is  prepared  concurrent  with  the 
subcontract  statement  of  woik  and  is  reviewed,  as  appropriate. 

Continued  on  next  page 
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Software 

Continued 


Documented 

procedures, 

continued 


Subcontract  Management  (SSM)  Procedures, 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

The  software  subcontractor  is  selected  based  on  an  evaluation  of  the 
subcontract  bidders'  ability  to  perform  the  work,  according  to  a 
documented  procedure.  (L2-49,  A2) 

This  procedure  covers  the  evaluation  of: 

□  Proposals  submitted  for  the  planned  subcontract. 

□  Prior  performance  records  on  similar  work,  if  available. 

□  The  geographic  locations  of  the  subcontract  bidders'  organizations 
relative  to  the  prime  contractor. 

□  Software  engineering  and  software  management  capabilities. 

□  Staff  available  to  perform  the  work. 

□  Prior  experience  in  similar  applications,  including  software  expertise 
on  the  subcontractor's  software  management  team. 

□  Available  resources. 

Changes  to  the  software  subcontractor's  statement  of  work,  subcontract 
terms  and  conditions,  and  other  commitments  are  resolved  according  to 
a  documented  procedure.  (L2-51,  A6) 

This  procedure  typically  specifies  that: 

□  All  affected  groups  of  both  the  prime  contractor  and  the 
subcontractor  are  involved. 

Continued  on  next  page 
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Software 

Continued 


Documented 

procedures, 

continued 


Subcontract  Management  (SSM)  Procedures, 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

Formal  reviews  to  address  the  subcontractor's  software  engineering 

accomplishments  and  results  are  conducted  at  selected  milestones 

according  to  a  documented  procedure.  (L2-53,  A9) 

This  procedure  typically  specifies  that: 

□  Reviews  are  preplanned  and  documented  in  the  statement  of  woric. 

□  Reviews  address  the  subcontractor’s  commitments  for,  plans  for,  and 
status  of  the  software  activities. 

□  Significant  issues,  action  items,  and  decisions  are  identified  and 
documented. 

□  Software  risks  are  addressed. 

□  The  subcontractor's  software  development  plan  is  refined,  as 
appropriate. 

The  prime  contractor's  software  quality  assurance  group  monitors  the 
subcontractor’s  software  quality  assurance  activities  according  to  a 
documented  procedure.  (L2-53,  A 10) 

This  procedure  typically  specifies  that: 

Q  The  subcontractor’s  plans,  resources,  procedures,  and  standards  for 
software  quality  assurance  are  periodically  reviewed  to  ensure  they 
are  adequate  to  monitor  the  subcontractor’s  performance. 

□  Regular  reviews  of  the  subcontractor  are  conducted  to  ensure  the 
approved  procedures  and  standards  are  being  followed. 

□  The  prime  contractor’s  software  quality  assurance  group  spot 
checks  the  subcontractor's  software  engineering  activities  and 
products. 

□  The  prime  contractor's  software  quality  assurance  group 
audits  the  subcontractor's  software  quality  assurance  records,  as 
appropriate. 

□  The  subcontractor’s  records  of  its  software  quality  assurance 
activities  are  periodically  audited  to  assess  how  well  the  software 
quality  assurance  plans,  standards,  and  procedures  are  being 
followed. 

Continued  on  next  page 
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Software 

Continued 


Documented 

procedures, 

continued 


Subcontract  Management  (SSM)  Procedures, 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
subcontract  management  process,  continued  from  the  previous  page. 


V 

Documented  Procedures 

Tlie  prime  contractor's  software  configuration  management  group 
monitors  the  subcontractor's  activities  for  software  configuration 
management  according  to  a  documented  procedure.  (L2-54,  A1 1) 

This  procedure  typically  specifies  that: 

□  The  subcontractor’s  plans,  resources,  procedures,  and  standards  for 
software  configuration  management  arc  reviewed  to  ensure  they  are 
adequate. 

□  The  prime  contractor  and  the  subcontractor  coordinate  their 
activities  on  matters  relating  to  software  configuration  management 
to  ensure  that  the  subcontractor's  products  can  be  readily  integrated 
or  incorporated  into  the  project  environment  of  the  prime 
contractor. 

□  The  subcontractor's  software  baseline  library  is  periodically  audited 
to  assess  how  well  the  standards  and  procedures  for  software 
configuration  management  are  being  followed  and  how  effective 
they  are  in  managing  the  software  baseline. 

The  prime  contractor  conducts  acceptance  testing  as  part  of  the 
delivery  of  the  subcontractor's  software  products  according  to  a 
documented  procedure.  (L2-55,  A12) 

This  procedure  typically  specifies  that: 

□  The  acceptance  procedures  and  acceptance  criteria  for  each  product 
are  defined,  reviev/ed,  and  approved  by  both  the  prime  contractor 
and  the  subcontractor  prior  to  the  test. 

□  The  results  of  the  acceptance  tests  are  documented. 

□  An  action  plan  is  established  for  any  software  product  that  does  not 
pass  its  acceptance  test. 
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Software  Quality  Assurance  (SQA)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
quality  assurance  process. 


~T 

Documented  Procedures 

References 

A  SQA  plan  is  prepared  for  the  software  project  according 
to  a  documented  procedure.  (L2-63,  Al) 

This  procedure  typically  specifies  that: 

□  The  SQA  plan  is  developed  in  the  early  stages  of,  and  in 
parallel  with,  the  overall  project  planning. 

□  The  SQA  plan  is  reviewed  by  the  affected  groups  and 
individuals. 

□  The  SQA  plan  is  managed  and  controlled. 

Deviations  identified  in  the  software  activities  and  software 

work  products  are  documented  and  handled  according  to  a 

documented  procedure.  (L2-67,  A7) 

This  procedure  typically  specifies  that: 

□  Deviations  from  the  software  development  plan  and  the 
designated  project  standards  and  procedures  are 
documented  and  resolved  with  the  appropriate  software 
task  leaders,  software  managers,  or  project  manager, 
where  possible. 

□  Deviations  from  the  software  development  plan  and  the 
designated  project  standards  and  procedures  not 
resolvable  with  the  software  task  leaders,  software 
managers,  or  project  manager  are  documented  and 
presented  to  the  senior  manager  designated  to  receive 
noncompliance  items. 

□  Noncompliance  items  presented  to  the  senior  manager 
are  periodically  reviewed  until  they  are  resolved. 

□  The  documentation  of  noncompliance  items  is  managed 
and  controlled. 
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Software  Configuration  Management  (SCM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  software 
configuration  management  process. 


T 

Documented  Procedures 

References 

A  SCM  plan  is  prepared  for  each  software  project  according 
to  a  documented  procedure.  (L2-76,  Al) 

This  procedure  typically  specifies  that: 

□  The  SCM  plan  is  developed  in  the  early  stages  of,  and  in 
parallel  with,  the  overall  project  planning. 

□  The  SCM  plan  is  reviewed  by  the  affected  groups. 

□  The  SCM  plan  is  managed  and  controlled. 

Change  requests  and  problem  reports  for  all  configuration 
items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure.  (L2-79,  A5) 

Changes  to  baselines  are  controlled  according  to  a 

documented  procedure.  (L2-80,  A6) 

This  procedure  typically  specifies  that: 

□  Reviews  and/or  regression  tests  are  performed  to  ensure 
that  changes  have  not  caused  unintended  effects  on  the 
baseline. 

□  Only  configuration  iteras/units  that  are  approved  by  the 
SCCB  are  entered  into  the  software  baseline  library. 

□  Configuration  items/units  are  checked  in  and  out  in  a 
manner  that  maintains  the  correemess  and  integrity  of 
the  software  baseline  library. 

Products  from  the  software  baseline  library  are  created  and 
their  release  is  controlled  according  to  a  documented 
procedure.  (L2-80,  A7) 

This  procedure  typically  specifies  that: 

□  The  SCCB  authorizes  the  creation  of  products  from  the 
software  baseline  library. 

□  Products  from  the  .noftware  baseline  library,  for  both 
internal  and  extemai  use,  are  built  only  from 
configuration  items^nits  in  the  software  baseline  library. 

Continued  on  next  page 
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Software  Configuration  Management  (SCM)  Procedures, 

Continued 


Documented  The  table  below  lists  the  recommended  documented  procedures  for  the  software 
procedures,  configuration  management  process,  continued  from  the  previous  page, 
continued  _ 


T 

Documented  Procedures 

References 

1 

■ 

The  status  of  configuration  items/units  is  recorded  according 

to  a  documented  procedure.  (L2-80,  A8) 

This  procedure  typically  specifies  that: 

□  The  configuration  management  actions  are  recorded  in 
sufficient  detail  so  that  the  content  and  status  of  each 
configuration  item/unit  are  known  and  previous  versions 
can  be  recovered. 

□  The  current  status  and  history  (i.e.,  changes  and  other 
actions)  of  each  configuration  item/unit  are  maintained. 

Software  baseline  audits  arc  conducted  according  to  a 

documented  procedure.  (L2-81,  AlO). 

This  procedure  typically  specifies  that: 

□  There  is  adequate  preparation  for  the  audit. 

□  The  integrity  cf  software  baselines  is  assessed. 

□  The  structure  and  facilities  of  the  configuration 
management  libraiy  system  are  reviewed. 

□  The  completeness  and  correctness  of  the  software 
baseline  library  contents  are  verified. 

□  Compliance  with  applicable  SCM  standards  and 
procedures  is  verified. 

□  The  results  of  the  audit  are  reported  to  the  project 
software  manager. 

□  Action  items  from  the  audit  are  tracked  to  closure. 
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Level  2  Summary 
Overview 


Section  purpose  The  purpose  of  this  section  is  to  provide  checklists  that  provide  a  summary  of  the 
repeatable  level  (level  2).  This  section  contains  three  perspectives  of  a  CMM  level. 

•  Key  process  area  (KPA)  specific  information: 

KPA  purpose 

KPA  goals 

•  Operational  framework  information  (from  a  maturity  level  viewpoint): 

Policies 

Standards 

Process  descriptions 

Procedures 

Training 

Tools 

•  Other  key  process  information  (from  a  maturity  level  viewpoint): 

Reviews  and  audits 

Work  products  managed  and  controlled 
Measurements 


Section  'fhis  section  contains  the  following  topics, 

overview 


Topic 

Page 

Level  2  -  KPA  Purposes 

L2-Summary-2 

Level  2  -  KPA  Goals 

L2-Summary-3 

Level  2  -  Policies 

L2-Summary-5 

Level  2  -  Standards 

L2-Summary-6 

Level  2  -  Process  Descriptions 

L2-Summary-7 

Level  2  -  Procedures 

L2-Summary-10 

Level  2  -  Training 

L2-Summary-13 

Level  2  -  Tools 

L2-Summary-14 

Level  2  -  Reviews  and  Audits 

L2-Summary-15 

Level  2  -  Work  Products  Managed  and  Controlled 

L2-Summary-20 

Level  2  -  Measurements 

L2-Summary-21 
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Level  2  -  KPA  Purposes 


Level  2  KPA 
purposes 


The  following  table  describes  the  purpose  of  each  key  process  area  in  the  CMM  at 
level  2. 


nr 

KPA 

Purpose  of  KPAs  at  Level  2 

RM 

The  purpose  of  Requirements  Management  is  to  establish  a  common 
understanding  between  the  customer  and  the  software  project  of  the 
customer's  requirements  that  will  be  addressed  by  the  software  project. 
(L2-1) 

SPP 

The  purpose  of  Software  Project  Planning  is  to  establish  reasonable 
plans  for  performing  the  software  engineering  and  for  managing  the 
software  project.  (L2-11) 

SPTO 

The  purpose  of  Software  Project  Tracking  and  Oversight  is  to  provide 
adequate  visibility  into  actual  progress  so  that  management  can  take 
effective  actions  when  the  software  project's  performance  deviates 
significantly  from  die  software  plans.  (L2-29) 

SSM 

The  purpose  of  Software  Subcontract  Management  is  to  select  qualified 
software  subcontractors  and  manage  them  effectively.  (L2-43) 

SQA 

The  purpose  of  Software  Quality  Assurance  is  to  provide  management 
with  appropriate  visibility  into  the  process  being  used  by  the  software 
project  and  of  the  products  being  built.  (L2-59) 

_ 

SCM 

The  purpose  of  Software  Configuration  Management  is  to  establish  and 
maintain  the  integrity  of  the  products  of  the  software  project  throughout 
the  project's  software  life  cycle.  (L2-71) 
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Level  2  KPA 
goals 


The  following  table  lists  the  goals  that  are  described  in  the  CMM  for  each  key  process 
area  at  level  2. 


T" 

KPA 

CMM  Goals  at  Level  2 

References 

RM 

System  requirements  allocated  to  software  are 
controlled  to  establish  a  baseline  for  software 
engineering  and  management  use.  (L2-2,  Gl) 

RM 

Software  plans,  products,  and  activities  are  kept 
consistent  with  the  system  requirements  allocated  to 
software.  (L2-2,  G2) 

SPP 

Software  estimates  are  documented  for  use  in  planning 
and  tracking  the  software  project.  (L2-12,  Gl) 

SPP 

Software  project  activities  and  commitments  are 
planned  and  documented.  (L2-12,  G2) 

SPP 

Affected  groups  and  individuals  agree  to  their 
commitments  related  to  the  software  project.  (L2-12, 
G3) 

SPTO 

Actual  results  and  performances  are  tracked  against  the 
software  plans.  (L2-30,  Gl) 

SPTO 

Corrective  actions  are  taken  and  managed  to  closure 
when  actual  results  and  performance  deviate 
significantly  from  the  software  plans.  (L2-30,  G2) 

SPTO 

Changes  to  software  commitments  are  agreed  to  by  the 
affected  groups  and  individuals.  (L2-30,  G3) 

SSM 

The  prime  contractor  selects  qualified  software 
subcontractors.  (L2-44,G1) 

SSM 

The  prime  contractor  and  the  software 
subcontractor  agree  to  their  commitments  to  each 
other.  (L2-44,G2) 

SSM 

The  prime  contractor  and  the  soft^vare 
subcontractor  maintain  ongoing  communicati''ns. 
(L2-44,  G3) 

SSM 

The  prime  contractor  tracks  the  software 
subcontractor’s  actual  results  and  performance  against 
its  conunitments.  (L2-44,G4) 

Continued  on  next  page 
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Level  2  KPA  The  following  table  lists  the  goals  that  are  described  in  the  CMM  for  each  key  process 
goals,  continued  area  at  level  2,  continued  from  the  previous  page. 


KPA 

CMM  Goals  at  Level  2 

SQA 

Software  quality  assurance  activities  are  planned.  (L2- 
60.  Gl) 

SQA 

Adherence  of  software  products  and  activities  to 
applicable  standards,  procedures,  and  requirements  is 
verified  objectively.  (L2-60.  G2) 

SQA 

Affected  groups  and  individuals  are  informed  of 
software  quality  assurance  activities  and  results.  (L2- 
60.  G3) 

SQA 

Noncompliance  issues  that  cannot  be  resolved  within 
the  software  project  are  addressed  by  senior 
management.  (L2-60.  G4) 

SCM 

Software  conJiguration  management  activities  are 
plarmed.  (L2-72.  Gl) 

SCM 

Selected  software  v'ork  products  are  identified, 
controlled,  and  available.  (L2-72,  G2) 

SCM 

Changes  to  identified  software  work  products  are 
controlled.  (L2-72.G3) 

SCM 

Affected  groups  and  individuals  are  informed  of  the 
status  and  content  of  software  baselines.  (L2-72.  G4) 

References 
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Level  2  policies  The  following  table  lists  the  recommended  policies  in  the  CMM  at  level  2. 


m 

KPA 

Description 

References 

■ 

RM 

Written  organizational  policy  for  managing  the  system 
requirements  allocated  to  software.  (L2-2,  Cl) 

■ 

SPP 

Written  organizational  policy  for  planing  a  software 
project.  (L2-12,  C2) 

■ 

SPTO 

Written  organizational  policy  for  managing  the 
software  project.  (L2-30,  C2) 

■ 

SSM 

Written  organizational  policy  for  managing  the 
software  subcontract.  (L2-44,  Cl) 

SQA 

Written  organizational  policy  for  unplementing 
software  quality  assurance  (SQA).  ^2-60,  Cl) 

1 

SCM 

Written  organizational  policy  for  implementing 
software  configuration  management  (SCM).  ^2-72, 
Cl) 
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Level  2 
standards 


Reference 


The  CMM  recommends  the  contents  of  the  following  woilc  products  at  level  2; 


Tl 

KPA 

Standards  at  Level  2 

References 

RM 

Allocated  requirements.  (L2-4,  Ab2, 1-3) 

SPP 

Statement  of  woric.  (L2-14,  Abl,  1) 

SPP 

Software  development  plan.  (L2-19,  A7, 1-10) 

SSM 

Contractual  agreement.  (L2-50,  A3, 1-8) 

SQA 

Software  quality  assurance  plan.  (L2-64,  A2, 1-10) 

SCM 

Software  configuration  management  plan.  (L2-77,  A2, 
1-2) 

Refer  to  the  Level  2  Standards  Checklists  for  additional  information  regarding  the 
content  of  each  standard. 
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RM  process 
description 


SPP  process 
description 


Requirements  Management  involves  establishing  and  maintaining  an  agreement  with 
the  customer  on  the  requirements  for  the  software  project.  This  agreement  is  referred 
to  as  tlie  "system  requirements  allocated  to  the  software."  The  "customer"  may  be 
interpreted  as  the  system  engineering  group,  the  marketing  group,  another  internal 
organization,  or  an  external  customer.  The  agreement  covers  both  the  technical  and 
nontechnical  (e.g.,  delivery  dates)  requirements.  The  agreement  forms  the  basis  for 
estimating,  planning,  performing,  and  tracking  the  software  project's  activities 
throughout  the  software  life  cycle. 

The  allocation  of  the  system  requirements  to  software,  hardware,  and  other  system 
components  (e.g.,  humans)  may  be  performed  by  a  group  external  to  the  software 
engineering  group  (e.g.,  the  system  engineering  group),  and  the  software  engineering 
group  may  have  no  direct  control  of  this  allocation.  Within  the  constraints  of  the 
project,  the  software  engineering  group  takes  appropriate  steps  to  ensure  that  the 
system  requirements  allocated  to  software,  which  they  are  responsible  for  addressing, 
are  documented  and  controlled. 

To  achieve  this  control,  the  software  engineering  group  reviews  the  initial  and  revised 
system  requirements  allocated  to  software  to  resolve  issues  before  they  are 
incorporated  into  the  software  project.  Whenever  the  system  requirements  allocated  to 
software  are  changed,  the  affected  software  plans,  woik  products,  and  activities  are 
adjusted  to  remain  consistent  with  the  updated  requirements.  (L2-1) 


Software  Project  Planning  involves  developing  estimates  for  the  wo±  to  be 
performed,  establishing  the  necessary  commitments,  and  defining  the  plan  to  perform 
the  work. 

The  software  planning  begins  with  a  statement  of  the  work  to  be  performed  and  other 
constraints  and  goals  that  define  and  bound  the  software  project  (those  established  by 
the  practices  of  the  Requirements  Management  key  process  area).  The  software 
planning  process  includes  steps  to  estimate  the  size  of  the  software  work  products  and 
the  resources  needed,  produce  a  schedule,  identify  and  assess  software  risks,  and 
negotiate  commitments.  Iterating  through  these  steps  may  be  necessary  to  establish 
the  plan  for  the  software  project  Ci  e.,  the  software  development  plan^ 

This  plan  provides  the  basis  for  perfonming  and  managing  the  software  project's 
activities  and  addresses  the  commitments  to  the  software  project's  customer  according 
to  the  resources,  constraints,  and  capabilities  of  the  software  project.  (L2-1 1) 


Continued  on  next  page 


CMU/SEI-94-HB-1 


L2-Summary-7 


Level  2  -  Process  Descriptions,  continued 


SPTO  process 
description 


SSM  process 
description 


Software  Proj.?ct  Tracking  and  Oversight  involves  tracking  and  reviewing  the  software 
accomplishments  and  results  against  documented  estimates,  commitments,  and  plans, 
and  adjusting  these  plans  based  on  the  actual  accomplishments  and  results. 

A  documented  plan  for  the  software  project  (i.e.,  the  software  development  plan,  as 
described  in  the  Software  Project  Planning  key  process  area)  is  used  as  the  basis  for 
tracking  the  software  activities,  communicating  status,  and  revising  plans.  Software 
activities  are  monitored  by  the  management  Progress  is  primarily  determined  by 
comparing  the  actual  software  size,  effort,  cost,  and  schedule  to  the  plan  when  selected 
software  work  products  are  completed  and  at  selected  milestones.  A^en  it  is 
determined  that  the  software  project's  plans  are  not  being  met,  corrective  actions  are 
taken.  These  actions  may  include  revising  the  software  development  plan  to  reflect 
the  actual  accomplishments  and  replanning  the  remaining  work  or  taking  actions  to 
improve  the  performance.  (L2-29) 


Software  Subcontract  Management  involves  selecting  a  software  subcontractor, 
establishing  commitments  with  the  subcontractor,  and  tracking  and  reviewing  the 
subcontractor's  performance  and  results.  These  practices  cover  the  management  of  a 
software  (only)  subcontract,  as  well  as  the  management  of  the  software  component  of 
a  subcontract  that  includes  software,  hardware,  and  possibly  other  system  components. 

The  subcontractor  is  selected  based  on  its  ability  to  perform  the  work.  Many  factors 
contribute  to  the  decision  to  subcontract  a  portion  of  the  prime  contractor's  work. 
Subcontractors  may  be  selected  based  on  strategic  business  alliances,  as  well  as 
technical  considerations.  The  practices  of  this  key  process  area  address  the  traditional 
acquisition  process  associated  with  subcontracting  a  defined  portion  of  the  work  to 
another  organization. 

When  subcontracting,  a  documented  a^eement  covering  the  technical  and 
nontechnical  (e.g.,  delivery  dates)  requirements  is  estabSshed  and  is  used  as  the  basis 
for  managing  the  subcontract.  The  work  to  be  done  by  the  subcontractor  and  the  plans 
for  the  work  are  documented.  The  standards  that  are  to  be  followed  by  the 
subcontractor  are  compatible  with  the  prime  contractor's  standards. 

The  software  planning,  tracking,  and  oversight  activities  for  the  subcontracted  work 
are  performed  by  the  subcontractor.  The  prime  contractor  ensures  that  these  plarming, 
tracking,  and  oversight  activities  are  performed  appropriately  and  that  the  software 
products  delivered  by  the  subcontractor  satisfy  their  acceptance  criteria.  The  prime 
contractor  works  with  the  subcontractor  to  manage  their  product  and  process 
interfaces.  (L2-43) 


Continued  on  next  page 


L2-Summary-8 


CMU/SEI-94-HB-1 


Level  2  -  Process  Descriptions,  continued 


SQA  process 
description 


SCM  process 
description 


Software  Quality  Assurance  involves  reviewing  and  auditing  the  software  products 
and  activities  to  verify  that  they  comply  with  the  applicable  procedures  and  standards 
and  providing  the  software  project  and  other  appropriate  managers  with  the  results  of 
these  reviews  and  audits. 

The  software  quality  assurance  group  works  with  the  software  project  during  its  early 
stages  to  establish  plans,  standards,  and  procedures  that  will  add  value  to  the  software 
project  and  satisfy  the  constraints  of  the  project  and  the  organization's  policies.  By 
participating  in  establishing  the  plans,  standards,  and  proce  lures,  the  software  quality 
assurance  group  helps  ensure  they  fit  the  project's  needs  and  verifies  tliat  they  will  be 
usable  for  performing  reviews  and  audits  throughout  the  software  life  cycle.  The 
software  quality  assurance  group  reviews  project  activities  and  audits  software  work 
products  throughout  the  life  cycle  and  provides  management  with  visibility  as  to 
whether  the  software  project  is  adhering  to  its  established  plans,  standards,  and 
procedures. 

Compliance  issues  are  first  addressed  within  the  software  project  and  resolved  there  if 
possible.  For  issues  not  resolvable  within  the  software  project,  the  software  quality 
assurance  group  escalates  the  issue  to  .'ui  appropriate  level  of  management  for 
resolution. 

This  key  process  area  covers  the  practices  for  the  group  performing  the  software 
quality  assurance  function.  The  practices  identifying  the  specific  activities  and  work 
products  that  the  software  quality  assurance  group  reviews  and/or  audits  are  generally 
contained  in  the  Verifying  Implementation  common  feature  of  the  other  key  process 
areas.  (L2-59) 


Software  Configuration  Management  involves  identifying  the  configuration  of  the 
software  (i.e.,  selected  software  work  products  and  their  descriptions)  at  given  points 
in  time,  systematically  controlling  changes  to  the  configuration,  and  maintaining  the 
integrity  and  traceability  of  the  configuration  throughout  the  software  life  cycle.  The 
work  products  placed  under  software  configuration  management  include  the  software 
products  that  are  delivered  to  the  customer  (e.g.,  the  software  requirements  document 
and  the  code)  and  the  items  that  are.  identified  with  or  required  to  create  these  software 
products  (e.g.,  the  compiler). 

A  software  baseline  library  is  established  containing  the  software  baselines  as  they  are 
developed.  Changes  to  baselines  and  the  release  of  software  products  built  from  the 
software  baseline  libraiy  arc  systematically  controlled  via  the  change  control  and 
configuration  auditing  Actions  of  software  configuration  management. 

This  key  process  area  covers  the  practices  for  perfomiing  the  software  configuration 
management  function.  The  practices  identifying  specific  configuration  items/units  are 
contained  in  the  key  process  areas  that  describe  the  development  and  maintenance  of 
each  configuration  item/unit.  (L2-71) 
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Level  2  -  Procedures 


Level  2 
procedures 


The  table  below  lists  the  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  2.  Refer  to  the  Level  2  Procedure 
Checklists  for  additional  information  regarding  the  content  of  each  documented 
procedure. 


KPA 

Documented  Procedures 

References 

RM 

lliere  are  no  required  procedures  for  the  RM  process. 

SPP 

Software  project  commitments  made  to  individuals  and 
groups  external  to  the  organization  are  reviewed  with 
senior  management  according  to  a  documented 
procedure.  (L2-17,  A4) 

SPP 

The  project’s  software  development  plan  is  developed 
according  to  a  documented  procedure.  (L2-18,  A6) 

SPP 

Estimates  for  the  size  of  the  software  work  products 
(or  changes  to  the  size  of  software  work  products)  are 
derived  according  to  a  documented  procedure.  (L2-21 , 
A9) 

SPP 

Estimates  for  the  software  project's  effort  and  costs  are 
derived  according  to  a  documented  procedure.  (L2-22, 
AIO) 

SPP 

Estimates  for  the  project's  critical  computer  resources 
are  derived  according  to  a  documented  procedure. 
(12-23,  All) 

SPP 

The  project's  software  schedule  is  derived  according  to 
a  documented  procedure.  (L2-23,  A12) 

SPTO 

The  project's  software  development  plan  is  revised 
according  to  a  documented  procedure.  (L2-33,  A2) 

SPTO 

Software  project  commitments  and  changes  to 
commitments  made  to  individuals  and  groups  external 
to  the  organization  are  reviewed  with  senior 
management  according  to  a  documented  procedure. 
(L2-35,  A3) 

SPTO 

Formal  reviews  to  address  the  accomplishments  and 
results  of  the  software  project  are  conducted  at  selected 
project  milestones  according  to  a  documented 
procedure.  (L2-39,  A13) 

Continueu  on  next  page 
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Level  2  -  Procedures,  continued 


Level  2 

procedures, 

continued 


The  table  below  lists  the  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  2,  continued  from  the  previous  page. 


"T 

KPA 

Documented  Proce  dures 

References 

SSM 

The  work  to  be  subcontracted  is  defined  and  planned 
according  to  a  documented  procedure.  (L2-47,  Al) 

SSM 

The  software  subcontractor  is  selected  based  on  an 
evaluation  of  the  subcontract  bidders'  ability  to 
perform  the  work,  according  to  a  documented 
procedure.  (L2-49,  A2) 

SSM 

Changes  to  the  software  subcontractor's  statement  of 
work,  subcontract  terms  and  conditions,  and  other 
commitments  are  resolved  according  to  a  documented 
procedure.  (L2*51,A6) 

SSM 

Formal  reviews  to  address  the  subcontractor's  software 
engineering  accomplishments  and  results  are 
conducted  at  selected  milestones  according  to  a 
documented  procedure.  (L2-53,  A9) 

SSM 

The  prime  contractor's  software  quality  a.isurance 
group  monitors  the  subcontractor's  software  quality 
assurance  activities  according  to  a  documented 
procedure.  (L2-53,A10) 

SSM 

The  prime  contractor's  software  configuration 
management  group  monitors  the  subcontractor’s 
activities  for  software  configuration  management 
according  to  a  documented  procedure.  (L2-54,  Al  1) 

SSM 

The  prime  contractor  conducts  acceptance  testing  as 
part  of  the  delivery  of  the  subcontractor’s  software 
products  according  to  a  documented  procedure.  (L2- 
55,  A 12) 

SQA 

A  SQA  plan  is  prepared  for  tlie  software  project 
according  to  a  documented  procedure.  (L2-63,  Al) 

Continued  on  next  page 
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Level  2  -  Procedures,  continued 


Level  2 

procedures, 

continued 


The  table  below  lists  die  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  2,  continued  from  the  previous  page. 


~T 

KPA 

Documented  Procedures 

References 

SQA 

Deviations  identified  in  the  software  activities  and 
software  work  products  are  documented  and  handled 
according  to  a  documented  procedure.  (L2-67,  A7) 

SCM 

A  SCM  plan  is  prepared  for  each  software  project 
according  to  a  documented  procedure.  (L2-76,  Al) 

SCM 

Change  requests  and  problem  reports  for  all 
configuration  items/units  arc  initiated,  recorded, 
reviewed,  approved,  and  tracked  according  to  a 
documented  procedure.  (L2-79,  A5) 

SCM 

Changes  to  baselines  are  controlled  according  to  a 
documented  procedure.  (L2-80,  A6) 

SCM 

Products  from  the  software  baseline  library  are  created 
and  their  release  is  controlled  according  to  a 
documented  procedure.  (L2-80,  A7) 

SCM 

The  status  of  configuration  itemsAmits  is  recorded 
according  to  a  documented  procedure  (L2-80,  A8) 

SCM 

Software  baseline  audits  are  conducted  according  to  a 
documented  procedure.  (L2-81,  A 10). 
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Level  2  training  llie  table  below  lists  the  training  recommended  in  the  CMM  at  level  2. 


KPA 

Training 

RM 

Members  of  the  software  engineering  group  and 
other  software-related  groups  are  trained  to  perform 
their  requirements  management  activities.  (L2-5,  Ab4) 

SPP 

The  software  managers,  software  engineers,  and 
other  individuals  involved  in  the  software  project 
planning  are  trained  in  the  software  estimating  and 
planning  procedures  applicable  to  their  areas  of 
responsibility.  (L2-16,  Ab4) 

SPTO 

The  software  managers  are  trained  in  managing  the 
technical  and  personnel  aspects  of  the  software  project. 
(L2-32.  Ab4) 

SPTO 

First-line  software  managers  receive  orientation  in 
the  technical  aspects  of  the  software  project.  (L2-32, 
Ab5) 

SSM 

Software  managers  and  other  individuals  who  are 
involved  in  establisliing  and  managing  the  software 
subcontract  are  trained  to  perform  these  activities. 
(L2-46,  Ab2) 

SSM 

Software  managers  and  other  individuals  who  are 
involved  in  managing  the  software  subcontract  receive 
orientation  in  the  technical  aspects  of  the  subcontract. 
(L2-46,  Ab3) 

SQA 

Members  of  the  SQA  group  are  trained  to  perform 
their  SQA  activities.  (J-2-62,  Ab3) 

SQA 

The  members  of  the  software  project  receive 
orientation  on  the  role,  responsibilities,  authority,  and 
value  of  the  SQA  group.  (1,2-63,  Ab4) 

SCM 

Members  of  the  SCM  group  are  trained  in  the 
objectives,  procedures,  and  methods  for  performing 
their  SCM  activities.  (L2-76,  Ab4) 

SCM 

Members  of  the  software  engineering  group  and 
other  software-related  groups  are  trained  to  perform 
their  SCM  activities.  (L2-76,  Ab5) 

References 
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Level  2  tools  The  table  below  lists  the  tools  recommended  in  the  CMM  for  level  2. 


T 

KPA 

Tools 

References 

RM 

Tools  to  support  the  activities  for  managing 
requirements.  (L2-5,  Ab3, 2) 

SPP 

Tools  to  support  software  project  planning  activities. 
(L2-16,Ab3,2) 

SPTO 

Tools  to  support  software  tracking.  (L2-32,  Ab3, 2) 

SSM 

Tools  to  support  managing  the  subcontract.  (L2-46, 
Abl,2) 

SQA 

Tools  to  support  the  SQA  activities.  (L2-62,  Ab2,  3) 

SCM 

Tools  to  support  the  SCM  activities.  (L2-75,  Ab3, 2) 

SCM 

A  configuration  management  library  system  is 

established  as  a  repository  for  the  software  baselines. 

(L2-77,  A3) 

This  library  system: 

□  Supports  multiple  control  levels  of  SCM. 

□  Provides  for  the  storage  and  retrieval  of 
configuration  items/units. 

□  Provides  for  the  sharing  and  transfer  of 
configuration  items/units  between  the  affected 
groups  and  between  control  levels  within  the 
Ebra^. 

□  Helps  in  the  use  of  product  standards  for 
configuration  items^units. 

□  Provides  for  the  storage  and  recovery  of  archive 
versions  of  configuration  items/units. 

□  Helps  to  ensure  correct  creation  of  products  from 
the  software  baseline  library. 

□  Provides  for  the  storage,  update,  and  retrieval  of 
SCM  records. 

□  Supports  production  of  SCM  reports. 

□  Provides  for  the  maintenance  .T  the  library 
structure  and  contents. 
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Level  2  -  Reviews  and  Audits 


Level  2  reviews 
and  audits 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2. 


KPA 

Review  or  Audit 

Review 

Participants 

References 

RM 

The  software  engineering  group 
reviews  allocated  requirements  before 
they  are  incorporated  into  the  software 
project.  (L2-5,  Al) 

Software 

engineering 

group 

RM 

Changes  to  the  allocated  requirements 
are  reviewed  and  incorporated  into  the 
software  project.  (L2-7,  A3) 

Not  specified 
in  CMM 

RM 

The  activities  for  managing  the 
allocated  requirements  are  reviewed 
with  senior  management  on  a 
periodic  basis.  (L2-9,  VI) 

Senior 

management 

RM 

The  activities  for  managing  the 
allocated  requirements  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
9,V2) 

Project 

manager 

RM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
managing  the  allocated  requirements 
and  reports  the  results.  (L2-9,  V3) 

SQA  group 

SPP 

Software  project  commitments  made 
to  individuals  and  groups  external  to 
the  organization  are  reviewed  with 
senior  management.  (L2-17,  A4) 

Senior 

management 

SPP 

The  activities  for  software  project 
planning  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L2- 
26,  VI) 

Senior 

management 

SPP 

The  activities  for  software  project 
plai^g  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  bas's.  (L2-26,  V2) 

Project 

manager 
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Level  2  -  Reviews  and  Audits,  Continued 


Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continued  from  the  previous  page. 


~T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SPP 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
software  project  planning  and  reports 
the  results  (L2-27,  V3) 

SQA  group 

I 

SPTO 

Software  project  commitments  and 
changes  to  commitments  made  to 
individuals  and  groups  external  to 
the  organization  are  reviewed  with 
senior  management  according  to  a 
documented  procedure.  (L2-35,  A3) 

Senior 

management 

SPTO 

The  software  engineering  group 
conducts  periodic  internal  reviews  to 
track  technical  progress,  plans, 
performance,  and  issues  against  the 
software  development  plan.  (L2-38, 

A 12) 

These  reviews  are  conducted  between: 

□  The  first-line  software  managers 
and  their  software  task  leaders. 

□  The  project  software  manager, 
ilrst-line  software  managers,  and 
other  software  managers,  as 
appropriate. 

Software 

engineering 

group 

First-line 

software 

managers 

Project 

software 

manager 

Software 

managers 

Software  task 
leaders 

SPTO 

Fornial  reviews  to  address  the 
accomplishments  and  results  of  tiie 
software  project  are  conducted  at 
selected  project  milestones  according 
to  a  documented  procedure.  (L2-39, 
A13) 

□  These  reviews  are  conducted  with 
the  customer,  end  user,  and 
affected  groups  within  the 
organization,  as  appropriate.  (L2- 
39,A13,2) 

Affected 

groups 

Customer 

End  user 

Software 

managers 

SPTO 

The  activities  for  software  project 
tracking  and  oversight  are  reviewed 
with  senior  management  o.i  a 
periodic  basis.  (L2-40,  VI) 

Senior 

management 
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Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continued  from  the  previous  page. 


~T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SPTO 

The  activities  for  software  project 
tracking  and  oversight  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (1.2- 
41,  V2) 

Project 

manager 

SPTO 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
software  project  tracking  and  oversight 
and  reports  the  results.  (L2-41,V3) 

SQA  group 

SSM 

A  documented  subcontractor’s 
software  development  plan  is  reviewed 
and  approved  by  the  prime 
contractor.  (L2-51,A4) 

Prime 

contractor 

SSM 

The  prime  contractor's  management 
conducts  periodic  status/coordinatiow 
reviews  with  the  software 
subcontractor's  management.  (L2- 
51,  A7) 

Prime 

contractor's 

management 

Sub¬ 

contractor's 

management 

SSM 

Periodic  technical  reviews  and 
interchanges  are  held  with  the 
software  subcontractor.  (L2-52,  A8) 

Software 

subcontrac¬ 

tor 

SSM 

Foimal  reviews  to  address  the 
subcontractor's  software  engineering 
accomplishments  and  results  are 
conducted  at  selected  milestones 
according  to  a  documented  procedure, 
(L2-53,  A9) 

Not  specified 
in  the  CMM 

SSM 

The  software  subcontractor’s 
performance  is  evaluated  on  a  periodic 
basis,  and  the  evaluation  is  reviewed 
with  the  subcontractor.  (L2  55,  A 13) 

Subcontrac¬ 

tor 

Continued  on  next  page 
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Level  2  -  Reviews  and  Audits,  continued 


Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  tlie  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continued  from  the  previous  page. 


V 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SSM 

The  activities  forn;anaging  the 
software  subcontract  are  reviewed 
with  senior  management  on  a 
periodic  basis.  (L2-56,  VI) 

Senior 

management 

SSM 

The  activities  for  managing  the 
software  subcontract  are  reviewed 
with  the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
56.  V2) 

Project 

manager 

SSM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
managing  the  software  subcontract  and 
reports  the  results.  (L2-57,  V3) 

SQA  group 

SQA 

The  SQA  group  participates  in  the 
preparation  and  review  of  the  project's 
software  development  plan,  standards, 
and  procedures.  (L2-65,  A3) 

SQA  group 

SQA 

The  SQA  group  reviews  the  software 
engineering  activities  to  verify 
compliance.  (L2-66,  A4) 

SQA  group 

SQA 

The  SQA  group  audits  designated 
software  woik  products  to  verify 
compliance.  (L2-66,  A5) 

SQA  group 

SQA 

The  SQA  group  conducts  periodic 
reviews  of  its  activities  and  findings 
with  the  customer's  SQA  personnel, 
as  appropriate.  (L2-67,  A8) 

SQA  group 

Customer's 

SQA 

personnel 

SQA 

The  SQA  activities  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L2-68,V1) 

Senior 

management 

Continued  on  next  page 
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Level  2  -  Reviews  and  Audits,  continued 


Level  2  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  2, 
continued  from  the  previous  page. 


KPA 

Review  or  Audit 

Review 

Participants 

References 

SQA 

The  SQA  activities  are  reviewed  with 
the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
69,  V2) 

Project 

manager 

SQA 

Experts  independent  of  the  SQA 
group  periodically  review  the 
activities  and  software  work  products 
of  the  project’s  SQA  group.  (L2-69, 
V3) 

Experts 
independent 
of  the  SQA 
group 

SCM 

Change  requests  and  problem  reports 
for  all  configuration  items/units  are 
initiated,  recorded,  reviewed, 
approved,  and  tracked  according  to  a 
documented  procedure.  (L2-79,  A5) 

Not  specified 
in  CMM 

SCM 

Software  baseline  audits  are  conducted 
according  to  a  documented  procedure. 
(L2-81,  AlO) 

Not  specified 
in  CMM 

SCM 

The  SCM  activities  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L2-82,V1) 

Senior 

management 

SCM 

The  SCM  activities  are  reviewed  with 
the  project  manager  on  both  a 
periodic  and  event-driven  basis.  (L2- 
83.  V2) 

Project 

manager 

SCM 

The  SCM  group  periodically  audits 
software  baselines  to  verify  that  they 
conform  to  the  documentation  that 
defines  them.  (L2-83,  V3) 

SCM  group 

SCM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for  SCM 
and  repo.ns  the  results.  (L2-83,  V4) 

SQA  group 
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Level  2  -  Work  Products  Managed  and  Controlled 


Level  2  work  The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
products  controlled  in  the  CMM  at  level  2. 

managed  and 
controlled 


KPA 

Work  Products  Managed  and  Controlled 

References 

RM 

Allocated  requirements.  (L2-7,  A2, 1) 

SPP 

Project's  software  development  plan.  (L2-13,  C2, 6) 

SPP 

Statement  of  work.  (L2-15,  Abl,  3; 

SPP 

Software  planning  data.  (L2-25,  A15, 2) 

SPTO 

Software  development  plan  (SDP).  (L2-34,  A2, 4) 
(Same  as  project’s  SDP  above  in  SPP) 

SPTO 

Software  replanning  data.  (L2-38,  A1 1, 2) 

SSM 

Subcontract  statement  of  work.  (L2-48,  Al,  3.5) 

SQA 

SQA  plan.  (L2-64,A1,3) 

SQA 

Documentation  of  noncompliance  items.  (L2-67,  A7, 

4) 

SCM 

SCM  plan.  (L2-77.A1,3) 

L2-Summary-20 
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Level  2  -  Measurements 


Level  2 

measurements 


The  table  below  describes  the  recommended  measurements  in  the  CMM  at  level  2. 


KPA 

Description 

References  | 

RM 

Measurements  to  determine  the  status  of  the  activities 
for  managing  the  allocated  requirements.  (L2-8,  M 1 ) 

SPP 

Software  planning  data.  (L2-25,  A 15) 

□  Information  recorded  includes  the  estimates  and 
the  associated  information  needed  to  reconstruct 
the  estimates  and  assess  their  reasonableness.  (L2- 
25,  A15, 1) 

SPP 

Measurements  to  determine  the  status  of  the  software 
planning  activities.  (L2-25,  M 1 ) 

SPTO 

.Actual  measurement  data  and  replanning  data  for  the 
software  project.  (L2-38,  All) 

SPTO 

Measurements  to  determine  the  status  of  the  software 
tracking  and  oversight  activities.  (L2-39,  Ml) 

SSM 

Measurements  to  determine  the  status  of  the  activities 
for  managing  the  software  subcontract.  (L2-55,  Ml) 

SQA 

Measurements  to  determine  the  cost  and  schedule 
status  of  the  SQA  activities.  (L2-68,  Ml) 

SCM 

Measurements  to  determine  the  status  of  the  SCM 
activities.  (L2-82, Ml) 
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L2-Sum/nary-22 
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Chapter  5.  Defined  Level  (Level  3) 

Overview 

Introduction  This  chapter  contains  the  checklists  for  level  3  of  the  CMM. 
In  this  chapter  This  chapter  contains  the  following  sections: 
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Level  3  Policy  Checklists 
Overview 


Introduction 


Purpose 


Checklist 

description 


In  this  section 


This  section  describes  the  explicit  policies  found  in  the  Capability  Maturity  Model 
at  maturity  level  3. 


The  purpose  of  the  policy  checklists  is  to  provide: 

•  Guidance  in  identifying  which  policies  are  recommended  by  the  CMM  at  level  3. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  policies  to  determine 
if  they  are  consistent  with  the  CMM  at  level  3. 

•  Information  that  can  be  used  to  develop  software  policies  so  that  they  are 
consistent  with  the  CMM  at  level  3. 


Each  checklist  contains  twc  subsections:  the  KPA  policies  and  the  KPA  goals.  The 
table  below  describes  these  two  subsections  of  a  policy  checklist. 


Subsection 

Description 

Policy  checklist 

This  subsection  contains  criteria  that  the  organizational 
policy  can  be  evaluated  against.  These  criteria  must  be 
addressed  by  organizational  policy  to  be  consistent  with  the 
CMM. 

Policy  goals 

This  subsection  is  a  reminder  to  policy  designers  and 
evaluators  to  keep  in  mind  the  KPA  goals  when  developing 
the  policies  for  each  KPA.  The  goals  can  be  thought  of  as 
the  results  of  implementing  an  effective  policy. 

This  section  covers  the  following  policies: 


Policies 

See  Page 

Organization  process  focus  policy 

L3-Policy-2 

Organization  process  definition  policy 

L3-Policy-3 

Training  program  policy 

L3-Policy-4 

Integrated  software  management  policy 

L3-Policy-5 

Software  product  engineering  policy 

L3-Policy-6 

Intergroup  coordination  policy 

L3-Policy-7 

Peer  reviews  policy 

L3-Policy-8 
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L3-Policy-1 


Organization  Process  Focus  (OPF)  Policy 


OPF  policy 
checklist 


OPF  policy 
goals 


The  organization  follows  a  written  organizational  policy  for  coordinating  software 
process  development  and  improvement  activities  across  the  organization  (L3-2, 
Cl).  This  policy  typically  specifies  that: 


Description 

References 

A  group  is  established  that  is  responsible  for  the 
organization-level  software  process  activities  and 
coordinating  these  activities  with  the  projects.  (L3-2,  Cl,  1) 

The  software  processes  used  by  the  projects  are  assessed 
periodically  to  determine  their  strengths  and  weaknesses. 
(L3-2,C1.2) 

The  software  processes  used  by  the  projects  are 
appropriately  tailored  from  the  organi'^.ation’s  standard 
software  process.  (L3-2,  Cl,  3) 

Improvements  to,  and  other  useful  information  on,  each 
project’s  software  process,  tools,  and  methods  are  available 
to  other  projects.  (L3-2,  Cl,  4) 

Implementation  of  an  effective  organizational  process  focus  policy  has  the 
following  results: 


K 

Results  of  Effectively  Implementing  OPF  Policy 

References 

Software  process  development  and  improvement  activities 
are  coordinated  across  the  organization.  (L3-1,  Gl) 

The  strengths  and  weaknesses  of  the  software  processes  used 
are  identified  relative  to  the  process  standard.  (L3-2,  G2) 

Organization-level  process  development  and  improvement 
activities  are  planned.  (L3-2,  G3) 

L3-Policy*2 
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Organization  Process  Definition  (OPD)  Policy 


OPD  policy 
checklist 


OPD  policy 
goals 


The  organization  follows  a  written  policy  for  developing  and  maintaining  a 
standard  software  process  and  related  process  assets  (L3-12,  Cl).  This  policy 
typically  specifies  that: 


Description 

References 

A  standard  software  process  is  defined  for  the  organization. 
(L3-12,  Cl,  1) 

A  project’s  defined  software  process  is  a  tailored  version  of 
the  organization’s  standard  software  process.  (L3-13,  Cl,  2) 

The  organization’s  software  process  assets  are  maintained. 
(L3-13.  Cl,  3) 

Information  collected  from  the  projects  is  organized  and 
used  to  improve  the  organization’s  standard  software 
process.  (L3-13,  Cl,  4) 

Implementation  of  an  effective  organizational  process  definition  policy  has  the 
following  results; 


V 

Results  of  Effectively  Implementing  OPD  Policy 

References 

A  standard  software  process  for  the  organization  is 
developed  and  maintained.  (L3-12,  Gl) 

Information  related  to  the  use  of  the  organization’s  standard 
software  process  by  the  software  projects  is  collected, 
reviewed,  and  made  available.  (L3-12,  G2) 
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L3-Policy-3 


Training  Program  (TP)  Policy 


TP  policy  The  organization  follows  a  written  policy  for  meeting  its  training  needs  (L3-26, 

checklist  Cl).  This  policy  typically  specifies  that: 


Description 

References 

The  needed  skills  and  knowledge  for  each  software 
management  and  technical  role  are  identified.  (L3-26,  Cl, 

1) 

Training  vehicles  for  imparting  skills  and  knowledge  are 
identified  and  approved.  (L3-26,  Cl,  2) 

Training  is  provided  to  build  the  skill  base  of  the 
organization,  to  fill  the  specific  needs  of  the  projects,  and  to 
develop  the  skills  of  individuals.  (L3-26,  Cl,  3) 

Training  is  developed  within  the  organization  or  obtained 
from  outside  the  organization  when  appropriate.  (L3-26, 

Cl,  4) 

TP  policy  goals  Implementation  of  an  effective  training  program  policy  has  the  following  results: 


m 

Results  of  Effectively  Implementing  TP  Policy 

References 

Training  activities  are  planned.  (L3-25,  Gl) 

1 

Training  for  developing  the  skills  and  knowledge  needed  to 
perform  software  management  and  technical  roles  is 
provided.  (L3-25,  G2) 

1 

Individuals  in  the  software  engineering  group  and 
software-related  groups  receive  the  training  necessary  to 
perform  their  roles.  (L3-26,  G3) 

L3-Pollcy-4 
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Integrated  Software  Management  (ISM)  Policy 


ISM  policy 
checklist 


ISM  policy 
goals 


The  project  follows  a  written  organizational  policy  requiring  that  the  software 
project  be  planned  and  managed  using  the  organization's  standard  software  process 
and  related  process  assets  (L3-38,  Cl).  This  policy  typically  specifies  that: 


Description 

References 

Each  project  documents  the  project's  defined  software 
process  by  tailoring  the  organization's  standard  software 
process.  (L3-39,  Cl,  1) 

1 

The  project's  deviations  from  the  organization's  standard 
software  process  are  documented  and  approved.  (L3-39,  Cl, 
2) 

Each  project  performs  its  software  activities  in  accordance 
with  the  project's  defined  software  process.  (L3-39,  Cl,  3) 

Each  project  collects  and  stores  appropriate  project 
measurement  data  in  the  organization's  software  process 
database.  (L3-39,  Cl,4) 

Implementation  of  an  effective  integrated  software  management  policy  has  the 
following  results: 


'T 

Results  of  Effectively  Implementing  ISM  Policy 

References 

The  project's  defined  software  process  is  a  tailored  version  of 
the  organization’s  standard  software  process.  (L3-38,  Gl) 

The  project  is  planned  and  managed  according  to  the 
project's  defined  software  process.  (L3-38,  G2) 
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Software  Product  Engineering  (SPE)  Policy 


SPE  policy 
checldist 


SPE  policy 
goals 


The  project  follows  a  written  organizational  policy  for  performing  the  software 
engineering  activities  (L3-60,  Cl).  This  policy  typically  specifies  that: 


Description 

References 

The  software  engineering  tasks  are  performed  in  accordance 
with  the  project's  defined  software  process.  (L3-60,  Cl,  1) 

Appropriate  methods  and  tools  are  used  to  build  and 
maintain  the  software  products.  (L3-60,  Cl,  2) 

The  software  plans,  tasks,  and  products  are  traceable  to  the 
system  requirements  allocated  to  software.  (L3-60,  Cl,  3) 

Implementation  of  an  effective  software  product  engineering  policy  has  the 
following  results; 


Results  of  Effectively  Implementing  SPE  Policy 

References 

The  software  engineering  tasks  are  defined,  integrated,  and 
consistently  performed  to  produce  the  software.,  (L3-60, 

Gl) 

Software  work  products  are  kept  consistent  with  each  other. 
(L3-60,  G2) 

L3-PoIicy-6 
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Intergroup  Coordination  (1C)  Policy 


IC  policy 
checklist 


IC  policy  goals 


The  project  follows  a  written  organizational  policy  for  establishing 
interdisciplinary  engineering  teams  (L3-84,  Cl).  This  policy  typically  specifies 
that: 


1 

Description 

References 

The  system  requirements  and  project-level  objectives  for  the 
project  are  defined  and  reviewed  by  all  affected  groups. 
(L3-84,  Cl,  1) 

The  engineering  groups  coordinate  their  plans  and 
objectives.  (L3-84,  Cl,  2) 

Managers  are  responsible  for  establishing  and  maintaining 
an  environment  to  facilitate  interaction,  coordination, 
support,  and  teamwork  between  the  project's  engineering 
groups,  between  the  project  and  the  customer  or  end  users, 
as  appropriate,  and  throughout  the  organization.  (L3-85, 

Cl,  3) 

Implementation  of  an  effective  intergroup  coordination  policy  has  the  following 
results: 


11 

Results  of  Effectively  Implementing  IGC  Policy 

References 

■ 

The  customer's  requirements  are  agreed  to  by  all  affected 
groups.  (L3-84,  Gl) 

■ 

The  commitments  between  the  engineering  groups  are 
agreed  to  by  the  affected  groups.  (L3-84,  G2) 

1 

The  engineering  groups  identify,  track,  and  resolve 
intergroup  issues.  {L3-84,  G3^ 
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Peer  Reviews  (PR)  Policy 


PR  policy 
checklist 


PR  policy  goals 


The  project  follows  a  written  organizational  policy  for  performing  peer  reviews 
(L3-94,  Cl).  This  policy  typically  specifies  that: 


V 

Description 

References 

The  organization  identifies  a  standard  set  of  software  work 
products  that  will  undergo  peer  review.  (L3-94,  Cl,  1) 

Each  project  identifies  the  software  work  products  that  will 
undergo  peer  review.  (L3-94,  Cl,  2) 

Peer  reviews  are  led  by  trained  peer  review  leaders.  (L3-94, 
Cl,  3) 

Peer  reviews  focus  on  the  software  work  product  being 
reviewed  and  not  on  the  producer.  (L3-94,  Cl,  4) 

Results  of  the  peer  reviews  are  not  used  by  management  to 
evaluate  the  performance  of  individuals.  (L3-94,  Cl,  5) 

Implementation  of  an  effective  Peer  Reviews  policy  has  the  following  results: 


■1 

Results  of  Effectively  Implementing  PR  Policy 

References 

Peer  reviews  are  planned.  (L3-93,  Gl) 

1 

Defects  in  the  software  work  products  are  identified  and 
removed.  (L3-93,  G2) 

L3-Policy-8 
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Level  3  Standards  Checklists 
Overview 


Introduction 


Definition 


Purpose 


What  the 
standards 
checklists  are 
not 


This  section  describes  the  recommended  content  of  selected  work  products  in  the 
CMM  at  maturity  level  3. 


A  standard  checklist  describes  the  content  of  a  work  product  as  recommended  by 
the  CMM. 


The  purpose  of  the  standards  checklists  is  to  provide: 

•  Guidance  in  identifying  the  contents  of  standard  work  products  that  are 
recommended  by  the  CMM  at  level  3. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  standards  to 
determine  if  they  are  consistent  with  the  CMM  at  level  3. 

•  Information  that  can  be  used  to  develop  software  standards  that  are  consistent 
with  the  CMM  at  level  3. 


The  standards  checklists  contain  only  what  is  recommended  by  the  CMM,  and  are 
not  complete  standards  in  themselves.  For  example,  the  standard  for  the  software 
development  plan  (SDP)  contains  only  content  recommended  by  the  CMM.  Other 
sources  for  the  content  of  a  SDP  should  also  be  considered,  such  as  ANSI/IEEE  Std 
1058.1-1987,  DOD-STD-2167,  DI-MCCR-80030,  etc. 


Continued  on  next  page 
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0V6rvi6W,  continued 


In  this  section  This  section  covers  the  following  standards: 


Standard 

KPA 

See  Page 

Action  plan 

OPF 

L3-Standards-3 

Software  development  and  improvement  plan 

OPF 

L3-Standards-4 

Organization’s  standard  software  process 

OPD 

L3-Standards-5 

Software  process  element 

OPD 

L3-Staudards-6 

Tailoring  guidelines  and  criteria 

OPD 

L3-Standards-7 

Software  project’s  training  plan 

TP 

L3-Standards-8 

Organization’s  training  plan 

TP 

L3-Standards-9 

Organizational  standards  for  training  courses 

TP 

L3-Standards-10 

Project’s  defined  software  process 

ISM 

L3-Standards-ll 

Software  design  documentation 

SPE 

L3-Standards-12 

Test  plan 

SPE 

L3-Standards-13 

Plan  for  intergroup  commitments 

IC 

L3-Standards-14 

Plans  for  peer  reviews 

PR 

L3-Staridards-15 

L3-Standard$-2 
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Action  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  an  action  plan: 


V 

Recommended  Content 

Which  assessment  findings  will  be  addressed.  (L3-6,  Al) 

Guidelines  for  implementing  the  changes  to  address  findings.  (L3-6,  Al) 

The  groups  or  individuals  responsible  for  implementing  the  changes.  (L3- 
6,  Al) 
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L3-StandardS'3 


Software  Process  Development  and  Improvement  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  plan  for  software  process  development  and  improvement.  This  plan: 


Recommended  Content 

Uses  the  action  plans  from  the  software  process  assessments  and  other 
organization  improvement  initiatives  as  primary  inputs.  (L3-7,  A2,  1) 

Defines  the  activities  to  be  performed  and  the  schedule  for  these  activities.  I 
(L3-7,  A2,  2)  1 

Specifies  the  groups  and  individuals  responsible  for  the  (software  process 
development  and  improvement)  activities.  (L3-7,  A2,  3) 

Identifies  the  resources  required,  including  staff  and  tools.  (L3-7,  A2,  4) 

L3-Standards-4 
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Organization’s  Standard  Software  Process 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  an  organization's  standard  software  process: 


Recommended  Content 

The  process  is  decomposed  into  constituent  process  elements  to  the 
granularity  needed  to  understand  and  describe  the  process.  (L3-17,  A2,  1) 

Each  process  element  is  described.  (L3-17,  A2,  2) 

[Refer  to  Level  3  Standards  for  additional  information  regarding  software 
process  elements.] 

The  relationships  of  the  process  elements  are  described  and  address  (L3-18, 
A2,  3): 

□  the  ordering, 

□  the  interfaces,  and 

□  the  interdependencies. 
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Software  Process  Element 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  software  process  element: 


V 

Recommended  Content 

The  required  procedures,  practices,  methods,  and  technologies.  (L3-17,  A2, 
2.1) 

The  applicable  process  and  product  standards.  (L3-17,  A2,  2.2) 

The  responsibilities  for  implementing  the  process.  (L3-18,  A2,  2.3) 

The  required  tools  and  resources.  (L3-18,  A2,  2.4) 

Inputs.  (L3-18,  A2,  2.5) 

The  software  work  products  produced.  (L3-18,  A2,  2.6) 

The  software  work  products  that  should  undergo  peer  review.  (L3-18,  A2, 
2.7) 

The  readiness  and  completion  criteria.  (L3-18,  A2,  2.8) 

The  product  and  process  data  to  be  collected.  (L3-18,  A2,  2.9) 
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Tailoring  Guidelines  and  Criteria 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  tailoring  guidelines  and  criteria  (for  tailoring  the  organization's  standard 
software  process).  These  guidelines  and  criteria  cover: 


Recommended  Content 

Selecting  and  tailoring  the  software  life  cycle  for  the  project.  (L3-19,  A4, 

1.1) 

Tailoring  the  organization's  standard  software  process  to  accommodate  the 
software  life  cycle  and  the  project’s  characteristics.  (L3-19,  A4,  1.2) 

Standards  for  documenting  the  project’s  defined  software  process.  (L3'20, 
A4,  1.3) 
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Software  Project’s  Trasnisig  Plan 


Standard 

checklist 


The  following  table  contains  what  the  C  IM  describes  as  the  recommended  content 
of  a  software  project’s  training  plan; 


Recommended  Content 

The  set  of  skills  needed  and  when  those  skills  are  needed.  (L3-29,  Al,  1) 

The  skills  for  which  training  is  required  and  the  skills  that  will  be  obtained 
via  other  vehicles.  (L3-29,  Al,2) 

The  training  that  is  required,  for  whom  it  is  required,  and  when  it  is 
required.  (L3-29,  Al,  3) 

How  training  will  be  provided.  (L3-30,  Al,  4) 
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Organization's  Training  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  organization's  training  plan: 


Recommended  Content 

The  specific  training  needed  within  the  organization  and  when  it  is  needed. 
(L3-32,  A3,  1) 

The  training  that  will  be  obtained  from  external  sources  and  training  that 
will  be  provided  by  the  training  group.  (L3-32,  A3,  2) 

The  fundiiig  and  resources  (including  staff,  tools,  and  facilities)  needed  to 
prepare  and  conduct  or  procure  the  training.  (L3-32,  A3,  3) 

Standards  for  instructional  materials  used  in  training  courses  developed  by 
the  training  group.  (L3-32,  A3,  4) 

The  schedule  for  developing  and  revising  the  training  courses  that  will  be 
developed  by  the  training  group.  (L3-32,  A3,  5) 

The  schedule  for  conducting  the  training,  based  on  the  projected  need  dates 
and  the  projected  number  of  students.  (L3-32,  A3,  6) 

The  procedures  for:  (L3-33,  A3,  7) 

□  selecting  the  individuals  who  will  receive  the  training, 

□  registering  and  participating  in  the  training, 

□  maintaining  records  of  the  training  provided,  and 

□  collecting,  reviewing,  and  using  training  evaluations  and  other  training 
feedback. 
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Organizational  Standards  for  Training  Courses 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  organizational  standards  for  training  courses.  These  standards  requires  that; 


Recommended  Content 

A  description  of  each  training  course  is  developed.  (L3-33,  A4,  1) 

The  materials  for  the  training  course  are  reviewed.  (L3-33,  A4,  2) 

The  materials  for  the  training  courses  are  managed  and  controlled.  (L3-33, 
A4,  3) 
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Project's  Defined  Software  Process 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  project's  defined  software  process: 


Recommended  Content 

Provisions  are  made  for  gathering,  analyzing,  and  reporting  measurement 
data  needed  to  manage  the  software  project.  (L3-44,  A4,  1) 

The  activities  for  software  estimating,  planning,  and  tracking  are  tied  to  the 
key  tasks  and  work  products  of  the  project’s  defined  software  process.  (L3- 
44,  A4,  2) 

Readiness  and  completion  criteria  are  established,  documented,  and  used  to 
authorize  initiation  and  determine  completion  of  key  tasks.  (L3-44,  A4,  3) 

Documented  criteria  are  defined  to  indicate  when  to  replan  the  software 
project.  (L3-45,  A4,  4) 

Technical  and  management  lessons  learned  are  documented  and  stored  in 
the  organization’s  library  of  software  process-related  documentation.  (L3- 
45,  A4,  5) 

Technical  and  management  lessons  learned  from  monitoring  the  activities  of 
other  projects  in  the  organization  are  systematically  reviewed  and  used  to 
estimate,  plan,  track,  and  replan  the  software  project.  (L3-45,  A4,  6) 

The  staffing  plan  addresses  the  software  project’s  needs  foi’  individuals  with 
special  skills  and  application  domain  knowledge.  (L3-45,  A4  7) 

Training  needs  are  identified  and  documented  to  fit  the  specific  needs  of  the 
software  project.  (L3-45,  A4,  8) 

The  software  plans  and  processes  followed  in  interacting  with  other  groups 
are  adjusted  to  account  for  disparities  with  these  groups  and  for  other 
potential  problems.  (L3-45,  A4,  9) 
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Software  Design  Documentation 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  software  design  documentation: 


V 

Recommended  Content 

The  software  components.  (L3-71,  A3,  8.1) 

The  internal  interfaces  between  software  components.  (L3-71,  A3,  8.1) 

The  software  interfaces  to  other  software  systems,  to  hardware,  and  to 
other  system  components  (e.g.,  humans).  (L3-71,  A3,  8.1) 
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Test  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  the  test  plan  (for  system  and  acceptance  testing): 


Recommended  Content 

The  overall  testing  and  verification  approach.  (L3-75,  A7,  2.1) 

Responsibilities  of  the  developing  organization,  subcontractors,  customer, 
and  end  users,  as  appropriate.  (L3-76,  A7,  2.2) 

Test  facility,  test  equipment,  and  test  support  requirements.  (L3-76,  A7, 
2.3) 

Acceptance  criteria.  (L3-76,  A7, 2.4) 
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Plan  for  Intergroup  Commitments 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  plan  for  intergroup  commitments.  This  plan  is: 


V 

Recommended  Content 

The  baseline  for:  (L3-88,  A3,  1) 

□  the  project  schedule, 

□  the  contractual  and  technical  aspects  of  the  project,  and 

□  the  assignment  of  responsibilities  to  the  engineering  groups. 

Updated  to  incorporate  all  intergroup  commitments  and  changes  to  these 
commitments.  (L3-88,  A3,  4) 

Updated  as  the  work  progresses  to  reflect  progress  and  plan  changes  at  the 
project  level,  particularly  when  major  project  milestones  are  completed  and 
when  plans  change  significantly.  (L3-88,  A3,  5) 
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Plans  for  Peer  Reviews 


Standard 

checklist 


The  following  table  contains  what  the  CMM  descnbes  as  the  recommended  content 
of  plans  for  peer  reviews.  These  plans: 


V 

Recommended  Content 

Identify  the  software  work  products  that  will  undergo  peer  review.  (L3-97, 
Al,  1) 

□  The  software  work  products  selected  include  the  set  identified  in  the 
organization's  standard  software  process.  (L3-97,  Al,  1.1) 

Specify  the  schedule  of  peer  reviews.  (L3-97,  Al,  2) 
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Level  3  Process  Checklists 
Overview 


Section  purpose 


In  this  section 


The  purpose  of  the  process  checklists  is  to  provide: 

•  Guidance  in  identifying  which  processes  are  required  by  the  CMM  at  level  3. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  processes  to 
determine  if  they  are  consistent  with  the  CMM  at  level  3. 

•  Information  that  can  be  used  to  develop  software  processes  that  are  consistent 
with  the  CMM  at  level  3. 


This  section  contains  checklists  for  the  following  key  process  areas: 


Key  Process  Area 

See  Page 

Organization  Process  Focus 

L3-Process-3 

Organization  Process  Definition 

L3-Process-25 

Training  Program 

L3-Process-49 

Integrated  Software  Management 

L3-Process-67 

Software  Product  Engineering 

L3-Process-103 

Intergroup  Coordination 

L3-Process-149 

Peer  Reviews 

L3-Process-179 
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Organization  Process  Focus  (OPF)  Process 
OPF  Process  -  Overview 


OPF  process 
purpose 


OPF  process 
description 


The  purpose  of  Organization  Process  Focus  is  to  establish  the  organizational 
responsibility  for  software  process  activities  that  improve  the  organization's  overall 
software  process  capability.  (L3-1) 


Organization  Process  Focus  involves  developing  and  maintaining  an  understanding 
of  the  organization's  and  projects'  software  processes  and  coordinating  the  activities 
to  assess,  develop,  maintain,  and  improve  these  processes. 

The  organization  provides  the  long-term  commitments  and  resources  to  coordinate 
the  development  and  maintenance  of  the  software  processes  across  current  and 
future  software  projects  via  a  group  such  as  a  software  engineering  process  group. 
This  group  is  responsible  for  the  organization's  software  process  activities.  It  is 
specifically  responsible  for  the  development  and  maintenance  of  the  organization's 
standard  software  process  and  related  process  assets  (as  described  in  the 
Organization  Process  Definition  key  process  area),  and  it  coordinates  the  process 
activities  with  the  software  projects.  (L3-1) 


Continued  on  next  page 
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OPF  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-5 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-9 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-10 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-l  1 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-13 

Exit  Criteria 

Description  of  when  the  process  is 

com**  ■ 

L3-Process-15 

Reviews  and 
Audits 

List  (/s  rev  -iws  ai.  audits. 

L3-Process-19 

Work  Products 
Managed  and 
Controlled 

Lu  o'-  work  products  to  be  managed  and 
controlled. 

L3-Process-20 

Measurements 

Description  of  process  measurements. 

L3-Process-21 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-22 

Training 

List  of  training. 

L3-Process-23 

Tools 

List  of  tools. 

L3-Process-24 

L3-Process-4 
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OPF  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  focus  process. 


< 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

A  summary  report  from  each  (senior 
management  review  of  the  activities  for 
software  process  development  and 
improvement)  is  prepared  and  distributed 
to  the  aHected  groups  and  individuals. 
(L3-10,  VI,  4) 

Group 

responsible  for 
the  organiza¬ 
tion’s  software 
process 
activities 

□  Where  possible,  (the  group  responsible 
for  the  organization’s  software 
process  activities)  is  staffed  by  a  core 
of  software  technical  professionals  who 
are  assigned  full  time  to  the  group, 
possibly  supported  by  others,  on  a  part- 
time  basis.  (L3-4,  Abl,  I) 

□  The  (group  responsible  for  the 
organization’s  software  process 
activities)  is  staffed  to  represent  the 
software  engineering  discipline  and 
software-related  disciplines.  (L3-4, 

Abl,  2) 

□  Members  of  the  group  responsible  for 
the  organization’s  software  process 
activities  receive  required  training  to 
perform  these  activities.  (L3-5,  Ab3) 

□  Where  appropriate,  training  (for  the 
organization’s  and  projects’  software 
processes)  may  be  prepared  and 
conducted  by  the  group  responsible 
for  the  organization’s  software 
process  activities  (e.g.,  software 
engineering  process  group)  or  by  the 
training  group.  (L3-8,  A6,  2) 

Groups 
involved  in 
implementing 
the  software 
processes 

The  groups  involved  in  implementing  the 
software  processes  are  informed  of  the 
organization’s  and  projects’  activities  for 
software  process  development  and 
improvement.  (L3-9,  A7) 

Continued  on  next  page 
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OPF  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  focus  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Individuals 

□  Experienced  individuals  who  have 
expertise  in  specialized  areas  are 
committed  to  support  (the  group 
responsible  for  the  organization’s 
software  process  activities).  (L3-5, 

Ab2,  1) 

□  A  summary  report  from  each  (senior 
management)  review  (of  the  activities 
for  software  process  development  and 
improvement)  is  prepared  and 
distributed  to  the  affected  groups  and 
individuals.  (L3-10,  Vl,4) 

Managers 

□  Senior  management  coordinates 
software  process  requirements  and 
issues  with  higher  level  staff  and 
managers.  (L3-3,  C3,  3.1) 

□  Senior  management  coordinates  with 
the  organization’s  managers  to  secure 
the  managers’  and  staffs  support  and 
paiticipation.  (L3-3,  C3,  3.2) 

Senior 

management 

□  Senior  management  sponsors  the 

organization’s  activities  for  software 

process  development  and  improvement. 

(L3-2,  C2) 

Senior  management; 

□  Demonstrates  to  the  organization’s 
staff  and  managers  its  commitment 
to  these  software  process  activities. 

□  Establishes  long-term  plans  and 
commitments  for  funding,  staffing, 
and  other  resources. 

□  Establishes  strategies  for  managing 
and  implementing  the  activities  for 
process  development  and 
improvement. 

Role  continues  on  the  next  page 

Continued  on  next  page 
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OPF  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  focus  process,  continued  from  the  previous  page. 


< 

Role 

Activities  Participated  in... 

Reference 

Senior 

management, 

continued 

□  Senior  management  oversees  the 
organization’s  activities  for  software 
process  development  and  improvement. 
(L3-3,  C3) 

Senior  management; 

□  Ensures  that  the  organization’s 
standard  software  process  supports 
its  business  goals  and  strategies. 

□  Advises  on  setting  priorities  for 
software  process  development  and 
improvement. 

□  Participates  in  establishing  plans  for 
software  process  development  and 
improvement. 

□  Coordinates  software  process 
requirements  and  issues  with 
higher  level  staff  and  managers. 

□  Coordinates  with  the 
organization’s  managers  to 
secure  the  managers’  and 
staff’s  support  and 
participation. 

□  The  activities  for  software  process 
development  and  improvement  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3- 10,  VI) 

Senior 

managers 

(The  organizational  plan  for  software 
process  development  and  improvement 
activities)  is  reviewed  and  agreed  to  by  the 
organization’s  software  managers  and 
senior  managers.  (L3-7,  A2,  6) 

Software 

engineering 

group 

Members  of  the  .software  engineering 
group  and  other  software-related  groups 
receive  orientation  on  the  organization’s 
software  process  activities  and  their  roles  in 
those  activities.  (L3-6,  Ab4) 

Continued  on  next  page 
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OPF  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  focus  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software 

managers 

(The  organizational  plan  for  software 
process  development  and  improvement 
activities)  is  reviewed  and  agreed  to  by  the 
organization’s  software  managers  and 
senior  managers.  (L3-7,  A2,  6) 

Software- 
related  groups 

Members  of  the  software  engineering 
group  and  other  software-related  groups 
receive  orientation  on  the  organization’s 
software  process  activities  and  their  roles  in 
those  activities.  {L3-6,  Ab4) 

Staff 

Senior  management  coordinates  software 
process  requirements  and  issues  with  higher 
level  staff  and  managers.  (L3-3,  C3,  3.1) 

Training 

group 

Where  appropriate,  training  for  the 
organization’s  and  projects’  software 
processes  may  be  prepared  and  conducted 
by  the  group  responsible  for  the 
organization’s  software  process  activities 
(e.g.,  software  engineering  process  group) 
or  by  the  training  group.  (L3-8,  A6,  2) 
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OPF  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  for  the  organization  process  focus  process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  organization  process  focus  process. 


Condition 

References 

The  organization  follows  a  written  organizational  policy  for 
coordinating  software  process  development  and 
improvement  activities  across  the  organization.  (L3-2,  Cl) 

[Refer  to  Level  3  Policies  for  additional  information 
regarding  OPF  policy.] 

Senior  management  sponsors  the  organization’s  activities 
for  software  process  development  and  improvement.  (L3-2, 
C2) 

Senior  management  oversees  the  organization’s  activities 
for  software  process  development  and  improvement.  (L3-3, 
C3) 

A  group  that  is  responsible  for  the  organization’s  software 
process  activities  exists.  (L3-3,  Abl) 

Where  possible,  the  group  responsible  for  the 
organization’s  software  process  activities  is  staffed  by  a 
core  of  software  technical  professionals  who  are  assigned 
full  time  to  the  group,  possibly  supported  by  others,  on  a 
part-time  basis.  (L3-4,  Abl,  1) 

The  group  responsible  for  the  organization’s  software 
process  activities  is  staffed  to  represent  the  software 
engineering  discipline  and  software-related  disciplines.  ('L3- 
4,  Abl,  2) 

Adequate  resources  and  funding  are  provided  for  the 
organization’s  software  process  activities.  (L3-4,  Ab2) 

Experienced  individuals  who  have  expertise  in  specialized 
areas  are  committed  to  support  the  group  responsible  for 
the  organization’s  software  process  activities,  (L3-5,  Ab2, 

1) 

Tools  to  support  the  organization’s  software  process 
activities  are  made  available.  (L3-5,  Ab2,  2) 

Members  of  the  group  responsible  for  the  organization’s 
software  process  activities  receive  required  training  to 
perform  these  activities.  (L3-5,  Ab3) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  receive  orientation  on  the 
organization’s  software  process  activities  and  their  roles  in 
those  activities.  (L3-6,  Ab4) 
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OPF  Process  -  Inputs 


Inputs 


The  table  below  lists  the  inputs  to  the  organization  process  focus  process. 


~T 

Input 

Org.  Input 

References 

Action  plans  from  the  software  process 
assessments.  (L3-7,  A2,  1) 

Business  goals  and  strategies.  (L3-3,  C3,  1) 

Improvements  to,  and  other  useful 
information  on,  each  project’s  software 
process,  tools,  and  methods.  (L3-2,  Cl,  4) 

New  processes,  methods,  and  tools  in 
limited  use  in  the  organization.  (L3-8,  A5) 

Organization  improvement  iniJatives.  (L3- 
7,  A2,  1) 

Organization’s  software  process  database. 
(L3-8,  A4) 

Organization’s  standard  software  process. 
(L3-2,  Cl,  3) 

Plan  for  the  organization’s  software 
process  development  and  improvement 
activities.  (L3-7,  A2) 

Progress  and  status  of  the  activities  to 
develop  and  improve  the  software  process. 
(L3-10,  VI,  1) 

Projects’  defined  software  process.  (L3-8, 
A3,  2) 

Software  process  issues.  (L3-3,  C3,  3.1) 

Software  process  requirements.  (L3-3,  C3, 
3.1) 

Software  process.  (L3-6,  Al) 

Software  processes  used  by  the  project. 
(L3-2,  Cl,  2) 
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OPF  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  organization  process  focus 
process. 


V 

Activities 

References 

The  software  process  is  assessed  periodically,  and  action 
plans  are  developed  to  address  the  assessment  findings.  (L3- 
6,  Al) 

The  organization  develops  and  maintains  a  plan  for  its 
software  process  development  and  improvement  activities. 
(L3-7,  A2) 

The  organization’s  and  projects’  activities  for  developing 
and  improving  their  software  processes  are  coordinated  at 
the  organization  level.  {L3-7,  A3) 

This  coordination  covers  the  development  and  improvement 
of: 

□  The  organization’s  standard  software  process. 

□  The  projects'  defined  software  processes. 

The  use  of  the  organization’s  software  process  database  is 
coordinated  at  the  organizational  level.  (L3-8,  A4) 

New  processes,  methods,  and  tools  in  limited  use  in  the 
organization  are  monitored,  evaluated,  and,  whe-  ^ 
appropriate,  transferred  to  other  parts  of  the  organization., 
(L3-8,  A5) 

Training  for  the  organization’s  and  projects’  software 
processes  is  coordinated  across  the  organization.  (L3-8,  A6) 

□  Plans  for  training  on  subjects  related  to  the 
organization’s  and  projects’  software  processes  are 
prepared. 

□  Where  appropriate,  training  may  be  prepared  and 
conducted  by  the  group  responsible  for  the 
organization’s  software  process  activities  (e.g.,  software 
engineering  process  group)  or  by  the  training  group. 

The  groups  involved  in  implementing  the  software 
processes  are  informed  of  the  organization’s  and  projects’ 
activities  for  software  process  development  and 
improvement.  (L3-9,  A7) 

Continued  on  next  page 
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OPF  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  organization  process  focus 
process,  continued  from  the  previous  page. 


Activities 

References 

Measurements  are  made  and  used  to  determine  the  status  of 
the  organization’s  process  development  and  improvement 
activities.  (L3-9,  Ml) 

The  activities  for  software  process  development  and 
improvement  are  reviewed  with  senior  management  on  a 
periodic  basis.  (L3-10,  VI) 

□  Progress  and  status  of  the  activities  to  develop  and 
improve  the  software  process  are  reviewed  against  the 
plan. 

□  Conflicts  and  issues  not  resolved  at  lower  levels  are 
addressed. 

□  Action  items  are  assigned,  reviewed,  and  tracked  to 
closure. 

□  A  summary  report  from  each  review  is  prepared  and 
distributed  to  the  affected  groups  and  individuals. 
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OPF  Process  -  Outputs 


Outputs 


The  table  below  lists  the  outputs  produced  by  the  organization  process  focus 
process. 


V 

Output 

Org.  Outputs 

References 

Action  items  (from  senior  management 
reviews  of  the  activities  for  software  process 
development  and  improvement).  {L3-10, 
VI,  3) 

Action  plans.  (L3-6,  Al) 

Assessment  findings.  (L3-6,  Al) 

Conflicts  and  issues  not  resolved  at  lower 
levels.  (L3-10,  Vl,2) 

Improvements  to,  and  other  useful 
information  on,  each  project’s  software 
process,  tools,  and  methods.  (L3-2,  Cl,  4) 

Long-term  plans  and  commitments  for 
funding,  staffing,  and  other  resources  (for 
the  organization’s  activities  for  software 
process  development  and  improvement). 
(L3-3,  C2,  2) 

Measurements  (to  determine  the  status  of 
the  organization’s  process  development 
and  improvement  activities).  (L3-9,  Ml) 

Plan  for  organizational  software  process 
development  and  improvement  activities. 
(L3-7,  A2) 

Plans  for  software  process  development 
and  improvement.  (L3-3,  C3,  3) 

Plans  for  training  on  subjects  related  to  the 
organization’s  and  projects’  software 
processes.  (L3-8,  A6,  1) 

Priorities  for  software  process  development 
and  improvement.  (L3-3,  C3,  2) 

Progress  and  status  of  the  activities  to 
develop  and  improve  the  software  process. 
(L3-10,  VI,  1) 

Schedule  for  the  software  process 
development  and  improvement  activities. 
(L3-7,  A2,  2) 

Software  process  issues.  (L3-3,  C3,  3.1) 

Software  process  requirements.  (L3-3,  C3, 
3.1) 

Continued  on  next  page 
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OPF  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  organization  process  focus 
process,  continued  from  the  previous  page. 


V 

Output 

Org.  Outputs 

References 

Strategies  for  managing  and  implementing 
the  activities  for  process  development  and 
improvement.  (L3-3,  C2,  3) 

Summary  report  from  each  (senior 
management)  review  of  the  activities  for 
software  process  development  and 
improvement.  (L3-10,  VI,  4) 
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OPF  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  focus  process. 


V 

Output 

State 

References 

Action  items  (from 
senior  management 
reviews  of  the 
activities  for  software 
process  development 
and  improvement) 

□  are  assigned.  (L3-10,  VI,  3) 

□  are  reviewed.  (L3-10,  VI,  3) 

□  are  tracked  to  closure.  (L3-10, 
VI,  3) 

Action  plans 

are  developed  to  address  software 
process  assessment  findings.  (L3-6, 
Al) 

Conflicts  and  issues 
not  resolved  at  lower 
levels 

are  addressed  (during  senior 
management  reviews  of  the  activities 
for  software  process  development 
and  improvement).  (L3-10,  VI,  2) 

Improvements  to,  and 
other  useful 
information  on,  each 
project’s  software 
process,  tools,  and 
methods 

are  available  to  other  projects.  (L3- 
2,  Cl,  4) 

Long-term  plans  and 
commitments  for 
funding,  staffing,  and 
other  resources  (for 
the  organization’s 
activities  for  software 
process  development 
and  improvement) 

are  established  ty  senior 
management.  (L3-3,  C2,  2) 

Measurements  (to 
determine  the  status 
of  the  organization’s 
process  development 
and  improvement 
activities) 

□  are  made.  (L3-9,  Ml) 

□  are  used.  (L3-9,  Ml) 

Continued  on  next  page 
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OPF  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  focus  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Plan  for 
organizational 
software  process 
development  and 
improvement 
activities 

□  is  developed  by  the  organization. 
(L3-7,  A2) 

□  is  maintained  by  the 
organization.  (L3-7,  A2) 

□  undergoes  peer  review  when 
initially  released  and  whenever 
major  revisions  are  made.  (L3-7, 
A2.  5) 

□  is  reviewed  and  agreed  to  by  the 
organization’s  software 
managers  and  senior  managers. 
(L3-7,  A2,  6) 

Plans  for  software 
process  development 
and  improvement 

are  established  with  the  participation 
of  senior  management.  (L3-3,  C3, 

3) 

Plans  for  training  on 
subjects  related  to  the 
organization’s  and 
projects’  software 
processes 

are  prepared.  (L3-8,  A6,  1) 

Priorities  for  software 
process  development 
and  improvement 

are  set  with  the  advice  of  senior 
management.  (L3-3,  C3,  2) 

Progress  and  status  of 
the  activities  to 
develop  and  improve 
the  software  process 

are  reviewed  against  the  plan.  (L3- 
10.  VI,  1) 

Schedule  for  the 
software  process 
development  and 
improvement 
activities 

is  defined  in  the  plan  (for 
organizational  software  process 
development  and  improvement 
activities).  (L3-7,  A2,  2) 

Software  process 
issues 

are  coordinated  by  senior 
management  with  higher  level  staff 
and  managers.  (L3-3,  C3,  3.1) 

Software  process 
requirements 

are  coordinated  by  senior 
management  with  higher  level  staff 
and  managers.  (L3-3,  C3,  3.1) 

Continued  on  next  page 
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OPF  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  focus  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Strategies  for 
managing  and 
implementing  the 
activities  for  process 
development  and 
improvement 

are  established  by  senior 
management.  (L3-3,  C2,  3) 

Summary  report 
from  each  (senior 
management)  review 
of  the  activities  for 
software  process 
development  and 
improvement 

□  is  prepared.  (L3-10,  VI,  4) 

□  is  distributed  to  the  affected 
groups  and  individuals.  (L3-10, 
VI,  4) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  organization  process  focus  process. 


V 

Condition 

References 

The  software  processes  used  by  the  projects  are  assessed 
periodically  to  determine  their  strengths  and  weaknesses. 
(L3-2,C1,2) 

The  software  processes  used  by  the  projects  are 
appropriately  tailored  from  the  organization’s  standard 
software  process.  (L3-2,  Cl,3) 

The  organization’s  standard  software  process  supports  its 
business  goals  and  strategies.  (L3-3,  C3,  1) 

The  software  process  is  asses.sed  periodically,  and  action 
plans  are  developed  to  address  the  assessment  findings.  (L3- 
6,  Al) 

The  organization’s  and  projects’  activities  for  developing 
and  improving  their  software  processes  are  coordinated  at 
the  organization  level.  (L3-7,  A3) 

This  coordination  covers  the  development  and  improvement 
of: 

□  The  organization’s  standard  software  process. 

□  The  projects’  defined  software  processes. 

The  use  of  the  organization’s  software  process  database  is 
coordinated  at  the  organizational  level.  (L3-8,  A4) 

Continued  on  next  page 
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OPF  Process  -  Exit  Criteria,  continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  organi:  ation  process  focus  process,  continued  from  the  previous  page. 


Condition 

References 

New  processes,  methods,  and  tools  in  limited  use  in  the 
organization  are  monitored,  evaluated,  and,  where 
appropriate,  transferred  to  other  parts  of  the  organization. 
(L3-8,  A5) 

Training  for  the  organization’s  and  projects’  software 
processes  is  coordinated  across  the  organization.  (L3-8,  A6) 

The  groups  involved  in  implementing  the  software 
processes  are  informed  of  the  organization’s  and  projects’ 
activities  for  software  process  development  and 
improvement.  (L3-9,  A7) 

The  activities  for  software  process  development  and 
improvement  are  reviewed  with  senior  management  on  a 
periodic  basis.  (L3-10,  VI) 
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OPF  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  leviews  and  audits  for  the  organization 
process  focus  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  plan  for  organizational  software 
process  development  and  improvement 
activities  undergoes  peer  review  when 
initially  released  nd  \/henever  major 
revisions  are  maot,.  *  '^3-7,  A2,  5) 

Not  speciHed  in 
the  CMM 

The  plan  for  organizational  software 
process  development  and  improvement 
activities  is  reviewed  and  agreed  to  by  the 
organization's  software  managers  and 
senior  managers.  (L3-7,  A2,  6) 

Software 

managers 

Senior 

managers 

The  activities  for  software  process 
development  and  improvement  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3-10,  VI) 

Senior 

management 

Progress  and  status  of  the  activities  to 
develop  and  improve  the  software  process 
are  reviewed  against  the  plan.  (L3-10,  VI, 

I) 

Not  specified  in 
the  CMM 
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OPF  Process  -  Work  Products  Managed  and  Controlled 


Work  products  There  are  no  work  products  that  are  recommended  to  be  managed  and  controlled 

managed  and  during  the  organization  process  focus  process. 

controlled 
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OPF  Process  -  Measurements 


Measurements 


The  table  below  lists  the  recommended  measurements  for  the  organization  process 
focus  process. 


Measurements 

References 

Measurements  to  determine  the  status  of  the  organization’s 
process  development  and  improvement  activities.  (L3-9, 

Ml) 

Examples  of  measurements  include: 

□  Work  completed,  effort  expended,  and  funds  expended 
in  the  organization’s  activities  for  process  assessment, 
development,  and  improvement  compared  to  the  plans 
for  these  activities. 

□  Results  of  each  software  process  assessment,  compared  to 
the  results  and  recommendations  of  previous 
assessments. 
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OPF  Process  -  Documented  Procedures 


Documented 

procedures 


There  are  no  activities  that  are  recommended  to  be  performed  according  to  a 
documented  procedure  in  the  organization  process  focus  process. 
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OPF  Process  -  Training 


Training 


The  table  belov/  lists  the  training  recommended  for  the  organization  process  focus 
process. 


Training 

References 

Members  of  the  group  responsible  for  the  organization’s 
software  process  activities  receive  required  training  to 
perform  these  activities.  (L3-5,  Ab3) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  receive  orientation  on  the 
organization’s  software  process  activities  and  their  roles  in 
those  activities.  (L3-6,  Ab4) 

Training  for  the  organization’s  and  projects’  software 
processes.  (L3-8,  A6) 

□  Where  appropriate,  training  may  be  prepared  and 
conducted  by  the  group  responsible  for  the 
organization's  software  process  activities  (e.g., 
software  engineering  process  group)  or  by  the  training 
group.  (L3-8,  A6,  2) 
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OPF  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  organization  process  focus 
process. 


Tools 

References 

Tools  to  support  the  organization’s  software  process 
activities.  (L3-5,  Ab2,  2) 

Examples  of  support  tools  include: 

□  statistical  analysis  tools, 

□  desktop  publishing  tools, 

□  database  management  systems,  and 

□  process  modeling  tools. 
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Organization  Process  Definition  (OPD)  Process 
OPD  Process  -  Overview 


OPD  process 
purpose 


OPD  process 
description 


The  purpose  of  Organization  Process  Definition  is  to  develop  and  maintain  a 
usable  set  of  software  process  assets  that  improve  process  performance  across  the 
projects  and  provide  a  basis  for  cumulative,  long-term  benefits  to  the  organization. 
(L3-11) 


Organization  Process  Definition  involves  developing  and  maintaining  the 
organization's  standard  software  process,  along  with  related  process  assets,  such  as 
descriptions  of  .oftware  life  cycles,  process  tailoring  guidelines  and  criteria,  the 
organization's  software  process  database,  and  a  library  of  software  process-related 
documentation. 

These  assets  may  be  collected  in  many  ways,  depending  on  the  organization's 
implementation  of  Organization  Process  Definition.  For  example,  the  descriptions 
of  the  software  life  cycles  may  be  an  integral  part  of  the  organization's  standard 
software  process  or  parts  of  the  library  of  software  process-related  documentation 
may  be  stored  in  the  organization's  software  process  database. 

The  organization's  software  process  assets  are  available  for  use  in  developing, 
implementing,  and  maintaining  the  projects'  defined  software  processes.  (The 
practices  related  to  the  development  and  maintenance  of  the  project's  defined 
software  process  are  described  in  the  Integrated  Software  Management  key  process 
area.)  (L3-11) 


Continued  on  next  page 
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OPD  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-27 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-29 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-30 

Activities 

Description  of  the  activities  of'  the 
process. 

L3-Process-3 1 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-33 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-35 

Reviews  and 

Audits 

List  of  reviews  and  audits. 

L3-Process-41 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-43 

Measurements 

Description  of  process  measurements. 

L3-Process-44 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-45 

Training 

List  of  training. 

L3-Process-46 

Tools 

List  of  tools. 

L3-Process-47 
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OPD  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  par.icipatc  in  the 
organization  process  definition  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Group 

responsible  for 
the  organiza¬ 
tion’s  software 
process 
activities  (e.g., 
software 
engineering 
process 
group) 

□  The  development  and  maintenance  of 
the  organization's  standard  software 
process  and  related  process  assets  is 
performed  or  coordinated  by  the 
group  responsible  for  the 
organization’s  software  process 
activities  (e.g.,  software  engineering 
process  group).  (L3-14,  Abl,  1) 

□  Changes  proposed  for  the 
organization's  standard  software 
process  are  documented,  reviewed,  and 
approved  by  the  group  responsible  for 
the  organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  before  they  are 
incorporated.  (L3-16,  Al,  6) 

□  Changes  proposed  for  the  descriptions 
of  software  life  cycles  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization’s 
software  process  activities  (e.g., 
software  engineering  process  group) 
before  they  are  incorporated.  (L3-18, 
A3,  2) 

□  Changes  proposed  for  the  tailoring 
guidelines  and  criteria  (for  the 
projects’  tailoring  of  the  organization’s 
standard  software  process)  are 
documented,  reviewed,  and  approved 
by  the  group  responsible  for  the 
organization’s  software  process 
activities  (e.g.,  software  engineering 
process  group)  before  they  are 
incorporated.  (L3-20,  A4,  2) 

Continued  on  next  page 
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OPD  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
organization  process  definition  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Individuals 
who  develop 
and  maintain 
the 

organization's 
standard 
software 
process  and 
related  process 
assets 

The  individuals  who  develop  and 
maintain  the  organization's  standard 
software  process  and  related  process 
assets  receive  required  training  to  perform 
these  activities.  (L3-14,  Ab2) 

Software 

quality 

assurance 

group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  organization’s 
activities  and  work  products  for  developing 
and  maintaining  the  organization's  standard 
software  process  and  related  process  assets 
and  reports  the  results.  (L3-23,  VI) 
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OPD  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  organization  process  definition  process. 


Input 

State 

References 

Descriptions  of 
software  life  cycles 

□  are  approved  for  use  by  the 
projects.  (L3-18,  A3) 

□  are  documented.  (L3-18,  A3) 

Organizational 
standards  (for 
documenting  the 
orfanization’s 
standard  software 
process) 

are  established.  (L3-17,  A2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  organization  process  definition  process. 


V 

Condition 

References 

The  organization  follows  a  written  policy  for  developing  and 
maintaining  a  standard  software  process  and  related  process 
assets.  (L3-12,  Cl) 

[Refer  to  Level  3  Policies  for  additional  information 
regarding  OPD  policy.] 

Adequate  resources  and  funding  are  provided  for 
developing  and  maintaining  the  organization’s  standard 
software  process  and  related  process  assets.  (L3-14,  Abl) 

The  development  and  maintenance  of  the  organization’s 
standard  software  process  and  related  process  assets  is 
performed  or  coordinated  by  the  group  responsible  for  the 
organization's  software  process  activities  (e.g.,  software 
engineering  process  group).  (L3-14,  Abl,  1) 

Tools  to  support  process  development  and  maintenance  are 
made  available.  (L3-14,  Abl,  2) 

The  individuals  who  develop  and  maintain  the 
organization's  standard  software  process  and  related 
process  assets  receive  required  training  to  perform  these 
activities.  (L3-14,  Ab2) 
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OPD  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  organization  process 
definition  process. 


Input 

Org.  Input 

References 

Candidate  documentation  items.  (L3-21, 

A6,  1) 

Changes  proposed  for  the  descriptions  of 
software  life  cycles.  (L3-18,  A3,  2) 

Changes  proposed  for  the  organization's 
standard  software  process.  (L3-16,  Al,  6) 

Changes  proposed  for  the  tailoring 
guidelines  and  criteria.  (L3-20,  A4,  2) 

Data  entered  into  the  (software  process) 
database.  (L3-21,A5,  2) 

Data  on  the  software  work  products 
(resulting  from  the  software  processes). 
(L3-20.  A5,  1) 

Data  on  the  software  processes.  (L3-20, 

A5,  1) 

Descriptions  of  software  life  cycles.  (L3- 
18,  A3) 

Guidelines  and  criteria  for  the  projects’ 
tailoring  of  the  organization’s  standard 
software  process.  (L3-19,  A4) 

Information  collected  from  the  projects  (to 
improve  the  organization’s  standard 
software  process).  (L3-13,  Cl,  4) 

Library  of  software  process-related 
documentation.  (L3-21,  A6) 

Organization’s  software  process  assets  or 
related  process  assets.  (L3-12,  Cl) 

Organization’s  standard  software  process. 
(L3-12,  Cl) 

Organization  standards.  (L3-17,  A2) 

Software  policies.  (L3-15,  Al,  1) 

Software  process  standards.  (L3-15,  Al,  1) 

Software  product  standards.  (L3-15,  Al, 

1) 

State-of-the-practice  software  engineering 
methods.  (L3-15,  Al,  3) 

State-of-the-practice  software  engineering 
tools.  (L3-15,  Al,3) 
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OPD  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  organization  process 
definition  process. 


V 

Activities 

References 

The  organization's  standard  software  process  is  developed 
and  maintained  according  to  a  documented  procedure.  (L3- 
15,  Al) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  organization's  standard  software  process  is  documented 
according  to  established  organization  standards.  (L3-17, 

A2) 

[Refer  to  Level  3  Standards  for  additional  information 
regarding  the  organization’s  standard  software  process.] 

Descriptions  of  software  life  cycles  that  are  approved  for  use 
by  the  projects  are  documented  and  maintained.  (L3-18, 

A3) 

□  Changc.s  proposed  for  the  descriptions  of  software  life 
cycles  are  documented,  reviewed,  and  approved  by  the 
group  responsible  for  the  organization's  software 
process  activities  (e.g.,  software  engineering  process 
group)  before  they  are  incorporated.  (L3-18,  A3,  2) 

□  The  descriptions  of  the  software  life  cycles  undergo  peer 
review  when  initially  documented  and  whenever 
significant  changes  or  additions  are  made.  (L3-19,  A3, 

3) 

□  The  descriptions  of  the  software  life  cycles  are  managed 
and  controlled.  (L3-19,  A3,  4) 

Guidelines  and  criteria  for  the  projects'  tailoring  of  the 
organization's  standard  software  process  are  developed  and 
maintained.  (L3-19,  A4) 

□  The  tailoring  guidelines  and  criteria  are  managed  and 
controlled.  (L3-20,  A4,  3) 

[Refer  to  Level  3  Standards  for  additional  information 
regarding  tailoring  guidelines  and  criteria.] 

Continued  on  next  page 
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OPD  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  organization  process 
definition  process,  continued  from  the  previous  page. 


Activities 

References 

The  organization's  software  process  database  is  established 

and  maintained.  (L3-20,  A5) 

□  The  database  is  established  to  collect  and  make  available 
data  on  the  software  processes  and  resulting  software 
work  products. 

□  The  data  entered  into  the  database  are  reviewed  to  ensure 
the  integrity  of  the  database  contents. 

□  The  database  is  managed  and  controlled. 

□  User  access  to  the  database  contents  is  controlled  to 
ensure  completeness,  integrity,  and  accuracy  of  the  data. 

A  library  of  software  process-related  documentation  is 

established  and  maintained.  (L3-21,  A6) 

□  Candidate  documentation  items  are  reviewed  and 
appropriate  items  that  may  be  useful  in  the  future  are 
included  in  the  library. 

□  The  documentation  items  are  catalogued  for  easy  access. 

□  Revisions  made  to  documentation  items  currently  in  the 
library  are  reviewed,  and  the  library  contents  are  updated 
as  appropriate. 

□  The  library  contents  are  made  available  for  use  by  the 
software  projects  and  other  software-related  groups. 

□  The  use  of  each  documentation  item  is  reviewed 
periodically,  and  the  results  are  used  to  maintain  the 
library  contents. 

□  The  library  contents  are  managed  and  controlled. 

Measurements  are  made  and  used  to  determine  the  status  of 
the  organization's  process  definition  activities.  (L3-22,  Ml) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  organization's  activities  and  work  products  for 
developing  and  maintaining  the  organization's  standard 
software  process  and  related  process  assets  and  reports  the 
results.  (L3-23,  VI) 
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OPD  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  organization 
process  definition  process. 


Output 

Org.  Output 

References 

Candidate  documentation  items  (for  the 
library  of  software  process-related 
documentation).  (L3-21,  A6,  1) 

Data  on  the  software  work  products 
(resulting  from  the  software  processes). 
(L3-20,  A5,  1) 

Data  on  the  software  processes.  (L3-20, 

A5,  1) 

Descriptions  of  software  life  cycles  or 
software  life  cycles.  (L3-18,  A3) 

External  process  interfaces  between  the 
software  process  and  the  processes  of  other 
affected  groups.  (L3-16,  Al,  5) 

Guidelines  and  criteria  for  the  projects’ 
tailoring  of  the  organization’s  standard 
software  process.  (L3-I9,  A4) 

Internal  process  interfaces  between  the 
software  disciplines.  (L3-15,  Al,  4) 

Library  of  software  process-related 
documentation  or  library  contents.  (L3- 
21,  A6) 

Measurements  (to  determine  the  status  of 
the  organization’s  process  definition 
activities).  (L3-22,  Ml) 

Organization’s  software  process  assets  or 
related  process  assets.  (L3-12,  Cl) 

Organization’s  standard  software  process. 
(L3-12,  Cl) 

Plans  for  introducing  changes  to  the 
software  process  of  ongoing  projects.  (L3- 
16,  Al,7) 

Process  element  relationships.  (L3-18,  A2, 
3) 

Process  element.  (L3-17,  A2,  1) 

Results  of  periodic  reviews  of  the  use  of 
software-process  related  documentation 
items.  (L3-22,  A6,  5) 

1  Results  of  SQA  group  reviews  and/or 

1  audits.  (L3-23,  VI) 

Continued  on  next  page 
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OPD  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  organization 
process  definition  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Revisions  made  to  documentation  items 
currently  in  the  (software  process-related 
documentation)  library.  (L3-22,  A6,  3) 

Software  process-related  documentation  or 
documentation  items.  (L3-21,  A6) 
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OPD  Process  -  Exit  Criteria 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
exit  criteria  to  exit  the  organization  process  definition  process. 


V 

Output 

State 

References 

Candidate  (software 
process-related) 
documentation  items 

□  are  reviewed.  (L3-21,A6,  1) 

□  are  included  in  the  library  (of 
software  process-related 
documentation),  if  they  may  be 
useful  in  the  future.  (L3-21,  A6, 
1) 

Data  on  the  software 
work  products 
(resulting  from  the 
software  processes) 

□  are  collected  into  the 
organization's  software  process 
database.  (L3-20,  A5) 

□  are  made  available  from  the 
organization's  software  process 
database.  (L3-20,  A5) 

□  completeness  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  integrity  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  accuracy  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,A5,  4) 

Data  on  the  software 
processes 

□  are  collected  into  the 
organization's  software  process 
database.  (L3-20,  A5) 

□  are  made  available  from  the 
organization's  software  process 
database.  (L3-20,  A5) 

□  completeness  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  integrity  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

□  accuracy  of  is  ensured  by 
controlling  access  to  the  software 
process  database.  (L3-21,  A5,  4) 

Continued  on  next  page 
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OPD  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Descriptions  of 
software  life  cycles 

□  are  documented.  (L3-18,  A3) 

□  are  maintained.  (L3-18,  A3) 

□  are  compatible  with  the 
organization's  standard  software 
process.  (L3-18,  A3,  1) 

□  undergo  peer  review  when 
initially  documented  and 
whenever  significant  changes  or 
additions  are  made.  (L3-19,  A3, 
3) 

□  are  managed  and  controlled. 
(L3-19,  A3,  4) 

External  process 
interfaces  between 
the  software  process 
and  the  processes  of 
other  affected  groups 

are  described.  (L3-16,  Al,  5) 

Guidelines  and 
criteria  for  the 
projects’  tailoring  of 
the  organization’s 
standard  software 
process 

□  are  developed.  (L3-19,  A4) 

□  are  maintained.  (L3-19,  A4) 

□  are  managed  and  controlled. 
(L3-20,  A4,  3) 

Internal  process 
interfaces  between 
the  software 
disciplines 

are  described.  (L3-15,  Al,  4) 

Library  of  software 
process-related 
documentation  or 
library  contents 

□  is  established.  (L3-21,  A6) 

□  is  maintained.  (L3-21,  A6) 

□  is  updated  as  appropriate.  (L3- 
22,  A6,  3) 

□  is  made  available  for  use  by  the 
software  projects  and  other 
software-related  groups.  (L3-22, 
A6,  4) 

□  is  managed  and  controlled.  (L3- 
22,  A6,  6) 
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OPD  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Measurements  (to 
determine  the  status 
of  the  organization's 
process  definition 
activities) 

□  are  made.  (L3-22,  Ml) 

□  are  used.  (L3-22,  Ml) 

Organization’s 
software  process 
assets  or  related 
process  assets 

□  are  maintained.  (L3-13,  Cl,  3) 

□  are  controlled.  (L3-23,  VI,  2) 

□  are  used  appropriately.  (L3-23, 
VI,  2) 
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OPD  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Organization’s 
standard  software 
process 

□  is  defined  for  the  organization. 
(L3-12,  Cl,  1) 

□  is  developed  according  to  a 
documented  procedure.  (L3'15, 
Al) 

□  is  maintained  according  to  a 
documented  procedure.  (L3-15, 
Al) 

□  satisfies  the  software  policies, 
process  standards,  and  product 
standards  imposed  on  the 
organization,  as  appropriate. 
(L3-15,  Al,  1) 

□  satisfies  the  software  process  and 
product  standards  that  are 
commonly  imposed  on  the 
organization’s  projects  by  their 
customers,  as  appropriate.  (L3- 
15,  Al,  2) 

□  incorporates  state-of-the-practice 
software  engineering  tools  and 
methods,  as  appropnate.  (L3-15, 
Al,3) 

□  description  undergoes  peer 
review  when  initially  developed 
and  whenever  significant  changes 
or  additions  are  made.  (L3-16, 
Al,8) 

□  is  placed  under  configuration 
management.  (L3-17,  Al,  9) 

□  is  documented  according  to 
established  organization 
standards.  (L3-17,  A2) 

□  is  decomposed  into  constituent 
process  elements  to  the 
granularity  needed  to  understand 
and  describe  the  process.  (L3- 
17,  A2,  1) 

Exit  criteria  continued  on  next  page 
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OPD  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  organization  process  definition  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Organization’s 
standard  software 
process,  continued 

□  is  controlled.  (L3-23,  VI,  2) 

□  is  used  appropriately.  (L3-23, 

VI,  2) 

Plans  for  introducing 
changes  to  the 
software  process  of 
ongoing  projects 

are  defined  as  appropriate.  (L3-16, 
AI,7) 

Process  element 
relationships 

□  are  described.  (L3-18,  A2,  3) 

□  address;  (L3-18,  A2,  3) 

□  the  ordering, 

□  the  interfaces,  and 

□  the  interdependencies. 

Process  element 

is  described.  (L3-17,  A2,  2) 

Results  of  periodic 
reviews  of  the  use  of 
documentation  items 

are  used  to  maintain  the  library  (of 
software  process-related 
documentation)  contents.  (L3-22, 
A6,5) 

Results  of  SQA 
group  reviews  and/or 
audits 

are  reported.  (L3-23,  VI) 

Revisions  made  to 
documentation  items 
currently  in  the 
library 

are  reviewed.  (L3-22,  A6,  3) 

Software  process- 
related 

documentation  or 
documentation  items 

□  are  catalogued  for  easy  access. 
(L3-22,  A6,  2) 

□  are  reviewed  periodically.  (L3- 
22,  A6,  5) 
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OPD  Process  -  Exit  Criteria,  Continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  organization  process  definition  process. 


V 

Condition 

References 

A  project’s  defined  software  process  is  a  tailored  version  of 
the  organization's  standard  software  process.  (L3-13,  Cl,  2) 

Information  collected  from  the  projects  is  organized  and 
used  to  improve  the  organization’s  standard  software 
process.  (L3-13,  Cl,4) 

Changes  proposed  for  the  descriptions  of  software  life  cycles 
are  documented,  reviewed,  and  approved  by  the  group 
responsible  for  the  organization's  software  process 
activities  (e.g.,  software  engineering  process  group)  before 
they  are  incorporated.  (L3-18,  A3,  2) 

Changes  proposed  for  the  tailoring  guidelines  and  criteria 
are  documented,  reviewed,  and  approved  by  the  group 
responsible  for  the  organization's  software  process 
activities  (e.g.,  software  engineering  process  group)  before 
they  are  incoiporated.  (L3-20,  A4,  2) 

The  organization's  software  process  database  is  established 

and  maintained.  (L3-20,  A5) 

□  The  database  is  established  to  collect  and  make  available 
data  on  the  software  processes  and  resulting  software 
work  products. 

□  The  data  entered  into  the  database  are  reviewed  to  ensure 
the  integrity  of  the  database  contents. 

□  The  database  is  managed  and  controlled. 

□  User  access  to  the  database  contents  is  controlled  to 
ensure  completeness,  integrity,  and  accuracy  of  the  data. 

The  software  quality  assurance  group  reviews  and/or  audits 
the  organization's  activities  and  work  products  for 
developing  and  maintaining  the  organization’s  standard 
software  process  and  related  process  assets  and  reports  the 
results.  (L3-23,  VI) 

The  appropriate  standards  are  followed  in  developing, 
documenting,  and  maintaining  the  organization's  standard 
software  process  and  related  process  assets.  (L3-23,  VI,  1) 
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OPD  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  organization 
process  definition  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

Changes  proposed  for  the  organization's 
standard  software  process  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g.,  software 
engineering  process  group)  before  they 
are  incorporated.  (L3-I6,  Al,  6) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group) 

The  description  of  the  organization’s 
standard  software  process  undergoes  peer 
review  when  initially  developed  and 
whenever  significant  changes  or  additions 
are  made.  (L3-16,  Al,  8) 

Not  specified  in 
the  CMM 

Changes  proposed  for  the  descriptions  of 
software  life  cycles  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g.,  software 
engineering  process  group)  before  they 
are  incorporated.  (L3-18,  A3,  2) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group) 

The  descriptions  of  the  software  life  cycles 
undergo  peer  review  when  initially 
documented  and  whenever  significant 
changes  or  additions  are  made.  (L3-19, 

A3,  3) 

Not  specified  in 
the  CMM 

Changes  proposed  for  the  tailoring 
guidelines  and  criteria  are  documented, 
reviewed,  and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e,g.,  software 
engineering  process  group)  before  they 
are  incorporated.  (L3-20,  A4,  2) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group; 

Continued  on  next  page 
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OPD  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  organization 
process  definition  process,  continued  from  the  previous  page. 


Review  or  Audit  j 

Review 

Participants 

References 

The  data  entered  into  the  (organization's 
software  process)  database  is  reviewed  to 
ensure  the  integrity  of  the  database 
contents.  (L3-2l,A5,  2) 

Not  specified  in 
theCMM 

Candidate  (software  process-related) 
documentation  items  are  reviewed  and 
appropriate  items  that  may  be  useful  in  the 
future  are  included  in  the  library  (of 
software-process  related  documentation). 
(L3-21,  A6,  1) 

Not  specified  in 
theCMM 

Revisions  made  to  (software  process- 
related)  documentation  items  currently  in 
the  library  are  reviewed,  and  the  library 
contents  are  updated  as  appropriate.  (L3- 
22,  A6,  3) 

Not  specified  in 
theCMM 

The  use  of  each  (software  process-related) 
documentation  item  is  reviewed 
periodically,  and  the  results  are  used  to 
maintain  the  library  contents.  (L3-22,  A6, 
5) 

Not  specifled  in 
theCMM 

The  software  quality  assurance  group 
reviews  and/or  audits  the  organization's 
activities  and  work  products  for  developing 
and  maintaining  the  organization's 
standard  software  process  and  related 
process  assets  and  reports  the  results.  (L3- 
23,  VI) 

At  a  minimum,  these  reviews  and/or  audits 
verify  that: 

□  The  appropriate  standards  are  followed 
in  developing,  documenting,  and 
maintaining  the  organization's  stand  ird 
software  process  and  related  process 
assets. 

□  The  organization's  standard  software 
process  and  related  process  assets  are 
controlled  and  used  appropriately. 

Software 

quality 

assurance 

group 

L3-Process-42 


CMU/SEI-94-HB-1 


OPD  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  organization  process  definition  process. 


Work  Products  Managed  and  Controlled 

References 

Description  of  the  organization's  standard  software  process.* 
(L3-17,  Al,  9) 

Descriptions  of  the  software  life  cycles.  (L3-19,  A3,  4) 

Tailoring  guidelines  and  criteria.  (L3-20,  A4,  3) 

Organization's  software  process  database.  (L3-21,  A5,  3) 

Library  of  software  process-related  documentation.  (L3-22, 
A6,  6) 

*Indicates  that  the  CMM  recommends  that  this  item  must  be  placed  under 
configuration  management 
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OPD  Process  -  Measurements 


Measurements 


The  table  below  lists  the  recommended  measurements  for  the  organization  process 
definition  process. 


/ 

\ 

Measurements 

References 

Data  on  the  software  work  products  (resulting  from  the 
software  process).  (L3-20,  A5,  1) 

Data  on  the  software  processes.  (L3-20,  A5,  1) 

Measurements  to  determine  the  status  of  the  organization's 
process  definition  activities.  (L3-22,  Ml) 

Examples  of  measurements  include; 

□  Status  of  the  schedule  milestones  for  process 
development  and  maintenance. 

□  Costs  for  the  process  definition  activities. 
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OPD  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  organization  process  definition  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


Documented  Procedure(s) 

References 

The  organization's  standard  software  process  is  developed 
and  maintained  according  to  a  documented  procedure.  (L3- 
15,  Al) 
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OPD  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  organization  process 
definition  process. 


T 

Training 

References 

The  individuals  who  develop  and  maintain  ihe 
organization's  standard  software  process  and  related 
process  assets  receive  required  training  to  perform  these 
activities.  (L3-I4,  Ab2) 
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OPD  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  organization  process 
definition  process. 


V 

Tools 

References 

Tools  to  support  process  development  and  maintenance. 
(L3-14  Abl,2) 

Examples  of  support  tools  include: 

□  desktop  publishing  tools, 

□  database  management  systems,  and 

□  process  modeling  tools. 

State-of-the-practice  software  engineering  tools.  (L3-15, 
Al,3) 

_J 

Oiganization’s  software  process  database.  (L3-20,  A5) 
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Training  Program  (TP)  Process 
TP  Process  -  Overview 


TP  process 
purpose 


TP  process 
description 


The  purpose  of  the  Training  Program  key  process  area  is  to  develop  the  skills  and 
knowledge  of  individuals  so  they  can  perform  their  roles  effectively  and 
efficiently.  (L3-25) 


Training  Program  involves  first  identifying  the  training  needed  by  the 
organization,  projects,  and  individuals,  then  developing  or  procuring  training  to 
address  the  identified  needs. 

Each  software  project  evaluates  its  current  and  future  skill  needs  and  determines 
how  these  skills  will  be  obtained.  Some  skills  are  effectively  and  efficiently 
imparted  through  informal  vehicles  (e.g.,  on-the-job  training  and  informal 
mentoring),  whereas  other  skills  need  more  formal  training  vehicles  (e.g., 
classroom  training  and  guided  self-study)  to  be  effectively  and  efficiently 
imparted.  The  appropriate  vehicles  are  selected  and  used. 

This  key  process  area  covers  the  practices  for  the  group  performing  the  training 
function.  The  practices  identifying  the  specific  training  topics  (i.e.,  knowledge  or 
skill  needed)  are  contained  in  the  Ability  to  Perform  common  feature  of  the 
individual  key  process  areas.  (L3-25) 


Continued  on  next  page 
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TP  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-51 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-52 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-53 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-54 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-55 

-Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-56 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L3-Process-60 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-61 

Measurements 

Description  of  process  measurements. 

L3-Process-62 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-63 

Tiaining 

List  of  training. 

L3-Process-64 

Tools 

List  of  tools. 

L3-Process-65 
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TP  Process  -  Roles 


Roles  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

training  program  process. 


V 

Rule 

Activities  Participated  in... 

Reference 

Affected 

groups 

The  organization's  training  plan  is  readily 
available  to  the  affected  groups  and 
individuals.  (L3-31,  A2,  6) 

Affected 

individuals 

□  The  organization's  training  plan  is 
reviewed  by  the  affected  individuals 
when  it  is  initially  released  and 
whenever  major  revisions  are  made. 
(L3-31,  A2,  4) 

□  The  organization's  training  plan  is 
readily  available  to  the  affected  groups 
and  individuals.  (L3-31,  A2,  6) 

Manager 

A  manager  is  designated  to  be  responsible 
for  implementing  the  organization's 
training  program.  (L3-28,  Ab2,  1) 

Senior 

management 

The  training  program  activities  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3-35,  VI) 

Software 

manager 

Software  managers  receive  orientation  on 
the  training  program.  (L3-29,  Ab4) 

Training 

group 

Members  of  the  training  group  have  the 
necessary  skills  and  knowledge  to  perform 
their  training  activities.  (L3-28,  Ab3) 
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TP  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  in  the  training  program  process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  training  program  process. 


Condition 

References 

The  organization  follows  a  written  policy  for  meeting  its 
training  needs.  (L3-26,  Cl) 

[Refer  to  Level  3  Policies  for  additional  information 
regarding  TP  policy.] 

A  group  responsible  for  fulfilling  the  training  needs  of  the 
organization  exists.  (L3-27,  Abl) 

Adequate  resources  and  funding  are  provided  for 
implementing  the  training  program.  (L3-27,  Ab2) 

A  manager  is  designated  to  be  responsible  for 
implementing  the  organization's  liaining  program.  (L3  28, 
Ab2,  1) 

Tools  to  support  the  training  program  activities  are  made 
available.  (L3-28,  Ab2,  2) 

Appropriate  facilities  are  made  available  to  conduct  training. 
(L3-28,  Ab2,  3) 

Members  of  the  training  group  have  the  necessary  skills  and 
knowledge  to  perform  their  training  activities.  (L3-28,  Ab3) 

Software  managers  receive  orientation  on  the  training 
program.  (L3-29,  Ab4) 
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TP  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  training  program  process. 


V 

Input 

Org.  Input 

References 

Changes  to  the  organization’s  training 
plan.  (L3-31,  A2,  3) 

Organization’s  training  plan.  (L3-30,  A2) 

[Refer  to  Level  3  Standards  for  additional 
information  regarding  the  organization’s 
training  plan.] 

Organizational  standards  for  training 
cou"ses.  (L3-33,  A4) 

[Refer  to  Level  3  Standards  for  additional 
information  regarding  organizational 
standards  for  training.] 

Procedures  for  collecting,  reviewing,  and 
using  training  evaluations  and  other 
training  feedback.  (L3-33,  A3,  7.4) 

Procedures  for  maintaining  records  of  the 
training  provided.  (L3-33,  A3,  7.3) 

— 

Procedures  for  registering  and 
participating  in  the  training.  (L3-33,  A3, 
7.2) 

Procedures  for  selecting  the  individuals 
who  will  receive  the  training.  (L3-33,  A3, 
7.1) 

Skills  needed  by  the  organization  and 
when  those  skills  are  needed.  (L3-30,  A2, 

2) 

Software  projects’  training  needs.  (L3-29, 
Al) 

Standards  for  instructional  materials  used 
in  training  courses.  (L3-32,  A3,  4) 

Training  courses  prepared  at  the 
organizational  level.  (L3-33,  A4) 

Training  evaluations.  (L3-33,  A3,  7.4) 

Training  plan  (for  each  software  project). 
(L3-29,  Al) 

Waiver  procedure  for  required  training. 
(L3-34,  A5) 
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TP  Process  -  Activities 


Activities 


The  table  below  lisis  the  recommended  activities  for  the  training  program  process. 


V 

Activities 

References 

Each  software  project  develops  and  maintains  a  training  plan 
that  specifies  its  training  needs.  (L3-29,  Al) 

The  organization's  training  plan  is  developed  and  revised 
according  to  a  documented  procedure.  (L3-30,  A2) 

[Refer  to  Level  3  Procedures  for  additional  information.] 

The  training  for  the  organization  is  performed  in 
accordance  with  the  organization's  training  plan.  (L3-32, 

A3) 

Training  courses  prepared  at  the  organization  level  are 
developed  and  maintained  according  to  organization 
standards.  (L3-33,  A4) 

A  waiver  procedure  for  required  training  is  established  and 
used  to  determine  whether  individuals  already  possess  the 
knowledge  and  skills  required  to  perform  in  their  designated 
roles.  (L3-34,  A5) 

Records  of  training  are  maintained.  (L3-34,  A6) 

□  Records  are  kept  of  all  students  who  successfully 
complete  each  training  course  or  other  approved 
training  activity. 

□  Records  are  kept  of  all  students  who  successfully 
complete  their  designated  required  training. 

□  Records  of  successfully  completed  ti.dning  are  made 
available  for  consideration  in  assignments  of  the  staff 
and  managers. 

Measurements  are  made  and  used  to  determine  the  status  of 
the  training  program  activities.  (L3-34,  Ml) 

Measurements  are  made  and  used  to  determine  the  quality 
of  the  training  program.  (L3-35,  M2) 

The  training  program  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L3-35,  VI) 

The  training  program  is  independently  evaluated  on  a 
periodic  basis  for  consistency  with,  and  relevance  to,  the 
organization's  needs.  (L3-36,  V2) 

The  training  program  activities  and  work  products  are 
reviewed  and/or  audited  and  the  results  are  reported.  (L3- 
36,  V3) 

[Refer  to  TP  Process  Reviews  and  Audits  for  additional 
information] 
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TP  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  training  program 
process. 


Output 

Org.  Outputs 

References 

Description  of  each  training  course.  (L3- 
33,  A4,  1) 

Materials  for  the  training  course.  (L3-33. 
A4,  2) 

Measurements.  (L3-34,  MI) 

Needed  skills  and  knowledge  for  each 
software  management  role.  (L3-26,  Cl,  I) 

Needed  skills  and  knowledge  for  each 
technical  role.  (L3-26,  Cl,  1) 

Organization’s  training  plan.  (L3-30,  A2) 

Records  of  all  students  who  successfully 
complete  each  training  course  or  other 
approved  training  activity.  (L3-34,  A6,  1) 

Records  of  all  students  who  successfully 
complete  their  designated  required 
training.  (L3-34,  A6,  2) 

Records  of  successfully  completed 
training.  (L3-34,  A6,  3) 

Records  of  training  or  training  records. 
(L3-34,  A6) 

Results  of  reviews  and/or  audits  of  the 
training  program  activities  and  work 
products.  (L3-36,  V3) 

Specific  training  to  be  provided.  (L3-30, 
A2,  2) 

Training  courses  prepared  at  the 
organization  level.  (L3-33,  A4) 

Training  plan  (for  each  software  project). 
(L3-29,  Al) 

Training  program  work  products.  (L3-36, 
V3) 

Training  vehicles  for  imparting  skills  and 
knowledge.  (L3-26,  Cl,2) 

Waiver  procedure  for  required  training. 
(L3-34,  A5) 
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TP  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  training  program  process. 


v 

Output 

State 

References 

Description  of  each 
training  course 

is  developed.  (L3-33,  A4,  I ) 

Materials  for  the 
training  course 

□  are  reviewed.  (L3-33,  A4,  2) 

□  are  managed  and  controlled. 
(L3-34.  A4,  3) 

Measurements 

□  are  made  to  determine  the  status 
of  the  training  program  activities. 
(L3-34.  Ml) 

□  are  used  to  determine  the  status 
of  the  training  program  activities. 
(L3-34,  Ml) 

□  are  made  to  determine  the 
quality  of  the  training  program. 
(L3-35,  M2) 

□  are  used  to  determine  the  quality 
of  the  training  program.  (L3-35, 
M2) 

Needed  skills  and 
knowledge  for  each 
software  management 
role 

are  identified.  (L3-26,  Cl,  1) 

Needed  skills  and 
knowledge  for  each 
technical  role 

are  identified.  (L3-26,  Cl,  1) 

Continued  on  next  page 
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TP  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  training  program  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Organization’s 
training  plan 

□  is  developed  according  to  a 
documented  procedure.  (L3-30, 
A2) 

□  is  revised  according  to  a 
documented  procedure.  (L3-30, 
A2) 

□  uses  the  software  projects’ 
training  needs  identified  in  their 
training  plans.  (L3-30,  A2,  1) 

□  is  revised,  as  appropriate,  to 
incorporate  changes.  (L3-31, 

A2,  3) 

□  is  reviewed  by  the  affected 
individuals  when  it  is  initially 
released  and  whenever  major 
revisions  are  made.  (L3-3 1 ,  A2, 
4) 

□  is  managed  and  controlled.  (L3- 
31,  A2,  5) 

□  is  readily  available  to  the  afTected 
groups  and  individuals.  (L3-3 1 , 
A2,  6) 

Records  of  all 
students  who 
successfully  complete 
each  training  course 
or  other  approved 
training  activity 

are  kept.  (L3-34,  A6,  1) 

Records  of  all 
students  who 
successfully  complete 
their  designated 
required  training 

are  kept.  (L3-34,  A6,  2) 

Records  of 
successfully 
completed  training 

are  made  available  for  consideration 
in  assignments  of  the  staff  and 
managers.  (L3-34,  A6,  3) 

Records  of  training 
or  training  records 

are  properly  maintained.  (L3-36, 

V3,  3) 

Continued  on  next  page 
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TP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  training  program  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Results  of  reviews 
and/or  audits  of  the 
training  program 
activities  and  work 
products 

are  reported.  (L3-36,  V3) 

Specific  training  to 
be  provided 

is  identified  based  on  the  skills 
needed  by  the  organization  and 
when  those  skills  are  needed.  (L3- 
30,  A2,  2) 

Training  courses 
prepared  at  the 
organization  level 

□  are  developed  according  to 
organization  standards.  (L3-33, 
A4) 

□  are  maintained  according  to 
organization  standards.  (L3-33, 
A4) 

Training  plan  (for 
each  software 
project) 

□  is  developed.  (L3-29,  Al) 

□  is  maintained.  (L3-29,  Al) 

□  specifies  the  software  project’s 
training  needs.  (L3-29,  Al) 

Training  program 
work  products 

□  are  reviewed.  (L3-36,  V3) 

□  are  audited.  (L3-36,  V3) 

Training  vehicles  for 
imparting  skills  and 
knowledge 

□  are  identified.  (L3-26,  Cl,  2) 

□  are  approved.  (L3-26,  Cl,  2) 

Waiver  procedure  for 
required  training 

□  is  established.  (L3-34,  A5) 

□  is  used  to  determine  whether 
individuals  already  possess  the 
knowledge  and  skills  required  to 
perform  in  their  designated  roles. 
(L3-34,  A5) 
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TP  Process  -  Exit  Criteria,  Continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  training  program  process. 


Condition 

References 

The  training  for  the  organization  is  performed  in 
accordance  with  the  organization’s  training  plan.  (L3-32, 

A3) 

The  training  program  activities  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L3-35,  VI) 

The  training  program  is  independently  evaluated  on  a 
periodic  basis  for  consistency  with,  and  relevance  to,  the 
organization's  needs.  (L3-36,  V2) 

The  training  program  activities  and  work  products  are 
reviewed  and/or  audited  and  the  results  are  reported.  (L3- 
36,  V3) 

CMU/SEI-94-HB-1 


L3-Process-59 


TP  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  training  program 
process. 


Review  or  Audit 

Review 

Participants 

References 

The  organization's  training  plan  is  reviewed 
by  the  aff'ected  individuals  when  it  is 
initially  released  and  whenever  major 
revisions  are  made.  (L3-31,A2,  4) 

Affected 

individuals 

The  materials  for  the  training  course  are 
reviewed.  (L3-33,  A4,  2) 

Not  specified  in 
the  CMM 

The  training  program  activities  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L3-35,  VI) 

Senior 

management 

The  training  program  is  independently 
evaluated  on  a  periodic  basis  for 
consistency  with,  and  relevance  to,  the 
organization's  needs.  (L3-36,  V2) 

Not  specified  in 
the  CMM 

The  training  program  activities  and  work 
products  are  reviewed  and/or  audited  and 
the  results  are  reported.  (L3-36,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify  that; 

□  The  process  for  developing  and 
revising  the  organization’s  training  plan 
is  followed. 

□  The  process  for  developing  and 
revising  a  training  course  is  followed. 

□  Training  records  are  properly 
maintained. 

□  Individuals  designated  as  requiring 
specific  training  complete  that  training. 

□  The  organization's  training  plan  is 
follo”'ed. 

Not  specified  in 
the  CMM 
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TP  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  training  program  process. 


T 

Work  Products  Managed  and  Controlled 

References 

The  organization's  training  plan.  (L3-31,  A2,  5) 

The  materials  for  the  training  courses.  (L3-34,  A4,  3) 
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TP  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  training  program 
process. 


V 

Measurements 

References 

Measurements  to  determine  the  status  of  the  training 
program  activities.  (L3-34,  Ml) 

Examples  of  measurements  include: 

□  Actual  attendance  at  each  training  course  compared  to 
the  projected  attendance. 

□  Progress  in  providing  training  courses  compared  to  the 
organization’s  and  projects’  training  plans. 

□  Number  of  training  waivers  approved  over  time. 

Measurements  to  determine  the  quality  of  the  training 
program.  (L3-35,  M2) 

Examples  of  measurements  include: 

□  Results  of  post-training  tests. 

□  Reviews  of  the  courses  from  the  students. 

□  Feedback  from  the  software  managers. 
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Documented 

procedures 


The  table  below  lists  the  activities  for  the  training  program  process  recommended 
to  be  performed  according  to  a  documented  procedure. 


Documented  Procedure(s) 

References 

The  organization's  training  plan  is  developed  and  revised 
according  to  a  documented  procedure.  (L3-30,  A2) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 
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TP  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  training  program  process. 


Training 

References 

Softw.are  managers  receive  orientation  on  the  training 
program.  (L3-29,  Ab4) 
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Tools 


The  table  below  lists  the  tools  recommended  for  the  training  program  process. 


V 

Tools 

References 

Tools  to  support  the  training  program  activities.  (L3-28, 

Ab2,  2) 

Examples  of  support  tools  include: 

□  workstations, 

□  instructional  design  tools, 

□  database  programs,  and 

□  packages  for  developing  presentation  materials. 
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Integrated  Software  Management  (iSM)  Process 
ISM  Process  -  Overview 


ISM  process 
purpose 


ISM  process 
description 


The  purpose  of  Integrated  Software  Management  is  to  integrate  the  software 
engineering  and  management  activities  into  a  coherent,  defined  software  process 
that  is  tailored  from  the  organization's  standard  software  process  and  related 
process  assets,  which  are  described  in  Organization  Process  Definition.  (L3-37) 


Integrated  Software  Management  involves  developing  the  project’s  def  .ied 
software  process  and  managing  the  software  project  using  this  defined  software 
process.  The  project's  defined  software  process  is  tailored  from  the  organization's 
standard  software  process  to  address  the  specific  characteristics  of  the  project. 

The  software  development  plan  is  based  on  the  project's  defined  software  process 
and  describes  how  the  activities  of  the  project’s  defined  software  process  will  be 
implemented  and  managed.  The  management  of  the  software  project's  size,  effort, 
cost,  schedule,  staffing,  and  other  resources  is  tied  to  the  tasks  of  the  project’s 
defined  software  process. 

Since,  the  projects’  defined  software  processes  are  all  tailored  from  the 
organization's  standard  software  process,  the  software  projects  can  share  process 
data  and  lessons  learned. 

The  basic  practices  for  estimating,  planning,  and  tracking  a  software  project  are 
described  in  the  Software  Project  Planning  and  Software  Project  Tracking  and 
Oversight  key  process  areas.  They  focus  on  recognizing  problems  when  they 
occur  and  adjusting  the  plans  and/or  performance  to  address  the  problems.  The 
practices  of  this  key  process  area  build  on,  and  are  in  addition  to,  the  practices  of 
those  two  key  process  areas.  The  emphasis  of  Integrated  Software  Management 
shifts  to  anticipating  problems  and  acting  to  prevent  or  minimize  the  effects  of 
these  problems.  (L3-37) 
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Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-69 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-72 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-73 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-75 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-78 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-83 

Reviews  and 

Audits 

List  of  reviews  and  audits. 

L3-Process-95 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-98 

Measurements 

Description  of  process  measurements. 

L3-Process-99 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-100 

Training 

List  of  training. 

L3-Process-101 

Tools 

List  of  tools. 

L3-Process-102 
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Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
integrated  software  management  process. 


VI 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

The  software  engineering  group  and  other 
affected  groups  and  individuals  are 
included  in  the  communications  on  the 
software  risks,  the  software  risk 
management  plans,  and  the  results  of  risk 
mitigation.  (L3-55,  AlO,  7) 

Affected 

individuals 

The  software  engineering  group  and  other 
affected  groups  and  individuals  are 
included  in  the  communications  on  the 
software  risks,  the  software  risk 
management  plans,  and  the  results  of  risk 
mitigation.  (L3-55,  AlO,  7) 

Customer 

Waivers  for  deviations  from  contractual 
software  process  requirements  are 
documented  and  are  reviewed  and 
approved  by  senior  management  and  the 
software  project's  customer,  as  appropriate. 
(L3-42,  Al,  4) 

Group 

responsible  for 

coordinating 

the 

organization’s 

software 

process 

activities  (e.g., 

software 

engineering 

process 

group) 

Tailoring  of  the  organization's  standard 
software  process  for  the  project  is  reviewed 
by  the  group  responsible  for  coordinating 
the  organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  and  approved  by  senior 
management.  (L3-42,  Al,  3) 

Group  that  is 
independent  of 
the  software 
engineering 
group 

A  group  that  is  independent  of  the 
software  engineering  group  reviews  the 
procedures  for  estimating  the  size  of  the 
software  work  products,  and  provides 
guidance  in  using  historical  data  from  the 
organization's  software  process  database  to 
establish  credible  e.stimates.  (L3-47,  A6,  I ) 

Individuals 
who  prepare 
the  size 
estimates 

The  individuals  who  prepare  the  size 
estimates  ensure  that  the  procedures  and 
data  used  in  the  estimates  are  appropriate. 
(L3-48,  A6,  l.l) 
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Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
integrated  software  managemerit  process,  continued  from  the  previous  page. 


Role 

Activities  Participi.'ted  in... 

Reference 

Individuals 
responsible  for 
ping  the 
project's 
defined 
software 
process 

The  individuals  responsible  for  developing 
the  project's  defined  software  process 
receive  required  training  in  how  to  tailor 
the  organization's  standard  software  process 
and  use  the  related  process  assets.  (L3-39, 
Ab2) 

Project 

manager 

The  activities  for  managing  the  software 
project  are  reviewed  wit/:  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-57,  V2) 

I 

Senior 

management 

□  Tailoring  of  the  organization's  star^^-^rd 
software  process  for  the  project  is 
reviewed  by  the  group  responsible  for 
coordinating  the  organization's 
software  process  activities  (e.g., 
software  engineering  process  group) 
and  approved  by  senior  management. 
(L3-42.  Al,  3) 

□  Waivers  for  deviations  from  the 
organization's  standard  software 
process  are  documented  and  are 
reviewed  and  approved  by  senior 
man.f.gement.  (L3-42,  Al,  3.1) 

□  Waivers  for  deviations  from  contractual 
software  process  requirements  are 
documented  and  are  reviewed  and 
approved  by  senior  management  and 
the  software  project's  customer,  as 
appropriate.  (L3-42,  Al,  4) 

□  The  activities  for  managing  the 
software  project  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L3-56,  VI) 

Software 

engineering 

group 

The  software  engineering  group  and  other 
affected  groups  and  individuals  are 
included  in  the  communications  on  the 
software  risks,  the  software  risk 
management  plans,  and  the  results  of  risk 

1  mitigation.  (L3-55,  A 10,  7) 

Continuea  on  next  page 


L3-Pri>cess*70 


CMU/SEI"94'HB-1 


ISM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
integrated  software  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software 

manager 

The  software  managers  receive  required 
training  in  m.anaging  the  technical, 
administrative,  and  personnel  aspects  of  the 
software  project  based  on  the  project's 
.fined  software  process.  (L3-40,  Ab3) 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  managing  the  software  project 
and  reports  the  results.  (L3-57,  V3) 

Team  of  peers 
and  experts 

When  the  validity  of  a  size  estimate  is 
questioned,  a  team  of  peers  and  experts 
reviews  the  estimate.  (L3-48,  A6,  1.2) 
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Input-based  The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
entry  criteria  before  entering  the  integrated  software  management  process. 


Input 

State 

References 

Available  capacity 
for  the  critical 
computer  resources 

provides  for  a  specified  reserve 
capacity  when  the  initial  estimate,’:  are 
made.  (L3-51,A8,  4) 

Software  effort,  cost, 
and  staffing  profile 
models 

□  if  used,  are  adapted  to  the 
project.  (L3-49,  A7,  1) 

□  use  available  historical  data 
where  appropriate.  (L3-49,  A7, 

1) 

Software  schedule 

identifies  specific  tasks  and 
milestones  whose  completion  can  be 
objectively  determined  (i.e.,  a  binary 
or  yes/no  determination).  (L3-5 1 , 

A9,  1.1) 

General  entry  The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
criteria  before  entering  the  integrated  software  management  process. 


n/ 

Condition 

References 

The  project  follows  a  written  organizational  policy  requiring 
that  the  software  project  be  planned  and  managed  using  the 
organization's  standard  software  process  and  related  process 
assets.  (L3'38,  Cl) 

Adequate  resources  and  funding  are  provided  for  managing 
the  software  project  using  the  project's  defined  software 
process.  (L3-39,  Abl) 

The  individuals  responsible  for  developing  the  project's 
defined  software  process  receive  required  training  in  how  to 
tailor  the  organization's  standard  software  process  and  use 
the  related  process  assets.  (L3-39,  Ab2) 

The  software  managers  receive  required  training  in 
managing  the  technical,  administrative,  and  personnel 
aspects  of  the  software  project  based  on  the  project's  defined 
software  process.  (L3-40,  Ab3) 
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Inputs 


The  tabic  below  lists  tlie  recommended  inputs  to  the  integrated  software 
management  process. 


Input 

Org.  Input 

References 

Actual  data  on  project  productivity  and 
other  new  software  costs.  (L3-50,  A7,  4.2) 

Available  capacity  for  the  critical  computer 
resources.  (L3-51,  A8,  4) 

Available  computer  resources.  (L3-50,  A8, 
3) 

Available  historical  data.  (L3-49,  A7,  1 ) 

Changes  proposed  by  the  software  project 
(to  the  project’s  defined  software  process). 
(L3-43,  A2,  1.2) 

Critical  dependencies  of  the  project's 
software  schedule.  (L3-51,  A9) 

Critical  paths  of  the  project's  software 
schedule.  (L3-51,  A9) 

Data  for  similar  software  projects.  (L3-46, 
A5,  1) 

_ I 

Historical  data  from  the  organization's 
software  process  database.  (L3-47,  A6,  1) 

Historical  experience,  simulations, 
prototyping,  or  analysis.  (L3-50,  A8,  1) 

Lessons  learned  (management)  from 
monitoring  the  activities  of  other  projects 
in  the  organization.  (L3-45,  A4,  6) 

Lessons  learned  (technical)  from 
monitoring  the  activities  of  other  projects 
in  the  organization.  (L3-45,  A4,  6) 

Lessons  learned  from  monitoring  the 
software  activities  of  the  organization’s 
projects.  (L3-43,  A2,  1.1) 

Organization's  library  of  software  proce' s- 
related  documentation.  (L3-45,  A4,  5) 

Organization's  software  process  database. 
(L3-39,  Cl,  4) 

Organization's  standard  software  process. 
(L3-38,  Cl) 
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Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  integrated  software 
management  process,  continued  from  the  previous  page. 


Input 

Org.  Input 

References 

Organization's  standards.  (L3-41,  Al,  1.3) 

Organization's  tailoring  guidelines  and 
criteria  (for  the  organization’s  standard 
software  process).  (L3-41,  Al,  1.2) 

Planned  computer  resources.  (L3-50,  A8, 

2) 

Process  and  work  product  measurement 
data.  (L3-43,  A2,  1.3) 

Project's  contractual  and  operational 
constraints.  (L3-41,  Al,  1.1) 

Project's  critical  computer  resource 
requirements.  (L3-50,  A8,  2) 

Project's  critical  computer  resources.  (L3- 
50,  A8) 

Project's  defined  software  process.  (L3-39, 
Cl,  3) 

Project's  software  development  plan.  (L3- 
44,  A3) 

Project's  software  risks.  (L3-52,  A 10) 

Related  process  assets.  (L3-38,  Cl) 

Risk  prioiities.  (L3-55,  AlO,  6.1) 

Software  design.  (L3-50,  A8,  2) 

Software  effort,  cost,  and  staffing  profile 
models.  (L3-49,  A7,  1) 

Software  requirements.  (L3-50,  A8,  2) 

Software  risk  management  plan.  (L3-53, 
AlO,  1) 

Software  schedule.  (L3-51,  A9,  1.1) 

Specific  needs  of  the  software  project. 
(L3-45,  A4,  8) 

System  requirements  allocated  to  software. 
(L3-50,  A8,  2) 
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Activities 


The  table  below  lists  the  required  activities  for  the  integrated  software  management 
process. 


1 

V 

Activities 

References 

The  project's  defined  software  process  is  de'  eloped  by 
tailoring  the  organization's  standard  software  process 
according  to  a  documented  procedure.  (I  3-41,  Al) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Each  project's  defined  software  process  is  revised  according 
to  a  documented  procedure.  (L3-43,  A2) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  development  plan,  which  describes  the 
use  of  the  project's  defined  software  process,  is  developed 
and  revised  according  to  a  documented  procedure.  (L3-44, 
A3) 

The  software  project  is  managed  in  accordance  with  the 
project's  defined  software  process.  (L3-44,  A4) 

[Refer  to  Level  3  Standards  for  additional  information 
regarding  the  project's  defined  software  process.] 

The  organization’s  software  process  database  is  used  for 
software  planning  and  estimating.  (L3-46,  A5) 

□  The  database  is  used  as  a  source  of  data  to  estimate,  plan, 
track,  and  replan  a  software  project;  data  for  similar 
software  projects  are  used  when  possible. 

□  Parameter  values  used  to  derive  estimates  for  software 
size,  effort,  cost,  schedule,  and  use  of  critical  computer 
resources  are  compared  to  those  of  other  software 
projects  to  assess  their  validity. 

□  Similarities  and  differences  to  the  other  projects  in 
terms  of  application  domain  and  design  approach 
are  assessed  and  recorded. 

□  Rationales  for  similarities  and  differences  between 
the  parameter  values  are  recorded. 

□  The  reasoning  used  to  judge  the  credibility  of  the 
project's  estimates  is  recorded. 

□  The  software  project  provides  appropriate  software 
planning  data,  replanning  data,  and  actual  measured  data 
for  storage  in  the  organization's  software  process 
database. 
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Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  integrated  software 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  size  of  the  software  work  products  (or  size  of  changes  to 
the  software  work  products)  is  managed  according  to  a 
documented  procedure.  (L3-47,  A6) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project’s  software  effort  and  costs  are  managed 
according  to  a  documented  procedure.  (L3-48,  A7) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  critical  computer  resources  are  managed 
according  to  a  documented  procedure.  (L3-50,  A8) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  critical  dependencies  and  critical  paths  of  the  project's 
software  schedule  are  managed  according  to  a  documented 
procedure.  (L3-51,  A9) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  risks  are  identified,  assessed, 
documented,  and  managed  according  to  a  documented 
procedure.  (L3-52,  A 10) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Reviews  of  the  software  project  are  periodically  performed 
to  determine  the  actions  needed  to  bring  the  software 
project's  performance  and  results  in  line  with  the  current  and 
projected  needs  of  the  business,  customer,  and  end  users,  as 
appropriate.  (L3-55,  All) 

Measurements  are  made  and  used  to  determine  the 
effectiveness  of  the  integrated  software  management 
activities.  (L3-56,  Ml) 

The  activities  for  managing  the  software  project  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L3-56,  VI) 
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Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  integrated  software 
management  process,  continued  from  the  previous  page. 


Activities 

References 

The  activities  for  managing  the  software  project  are  reviewed 
with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-57,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  managing  the  software 
project  and  reports  the  results.  (L3-57,  V3) 

[Refer  to  ISM  Process  Reviews  and  Audits  for  additional 
information.] 
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Outputs 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process. 


V 

Output 

Org.  Outputs 

References 

Actions  needed  to  bring  the  software 
project's  performance  and  results  in  line 
with  the  current  and  projected  needs  of  the 
business,  customer,  and  end  users.  (L3-55, 
All) 

Actual  expenditures  over  time  and  against 
work  completed.  (L3-49,  A7,  4) 

Actual  measured  data  (from  the  software 
project).  (L3-47,  A5,  3) 

Alternatives  for  each  software  risk.  (L3-54, 
AlO,  3) 

Changes  to  the  project's  defined  software 
process  derived  from  changes  proposed  by 
the  software  project.  (L3-43,  A2,  1 .2) 

Changes  to  the  project's  defined  software 
process  derived  from  lessons  learned  from 
monitoring  the  software  activities  of  the 
organization's  projects.  (L3-43,  A2,  1.1) 

Changes  to  the  project's  defined  software 
process  derived  from  process  and  work 
product  measurement  data.  (L3-43,  A2, 

1.3) 

Changes  to  the  project's  defined  software 
process.  (L3-43,  A2,  2) 

Commitments.  (L3-51,  A9,  1) 

Completion  criteria  (for  key  tasks).  (L3- 
44,  A4,  3) 

Contingency  factor  applied  to  the  size 
estimate  (of  the  software  work  product)  for 
each  software  element  identified  as  a 
software  risk.  (L3-48,  A6,  2) 

Costs.  (L3-51,A9,  1) 

Criteria  for  selecting  among  the  alternatives 
for  each  software  risk.  (L3-54,  AlO,  3) 

Critical  dependencies  (of  the  project’s 
software  schedule).  (L3-51,  A9,  2) 

Description  of  the  project's  defined 
software  process.  (L3-41,A1,2) 
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ISM  Process  -  Outputs,  Continued 


Outputs,  The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 

continued  process,  continued  from  the  previous  page. 


V 

Output 

Org.  Output' 

References 

Documented  criteria  to  indicate  when  to 
replan  the  software  project.  (L3-45,  A4,  4) 

Effort  and  cost  threshold  for  each 
individually  managed  software  task  or 
stage.  (L3-50,  A7,  5) 

Effort  to  modify  and  incorporate  reusable 
components.  (L3-48,  A6,  3.2) 

Estimates  for  the  project’s  critical  computer 
resources.  (L3-50,  A8,  1) 

Factors  which  could  significantly  affect  the 
size  of  the  software  work  products.  (L3- 
48,  A6,  4) 

Information  obtained  from  monitoring  the 
(software)  risks.  (L3-55,  AlO,  6.2) 

1 

Initial  release  of  the  software  risk 
management  plan.  (L3-54,  AlO,  4) 

1 

Lessons  learned  (management).  (L3-45, 

A4,  5) 

1 

Lessons  learned  (technical).  (L3-45,  A4, 

5) 

1 

Lessons  learned  from  monitoring  the 
software  activities  of  the  organization’s 
projects.  (L3-43,  A2,  1.1) 

1 

Major  revisions  to  the  software  risk 
management  plan.  (L3-.54,  AlO,  4) 

1 

Measurement  data  needed  to  manage  the 
software  project.  (L3-44,  A4,  1) 

1 

Measurements  (to  determine  the 
effectiveness  of  the  integrated  software 
management  activities).  (L3-56,  Ml) 

■ 

Milestones.  (L3-51,A9,  1) 

1 

Organization's  software  process  database. 
(L3-46,  A5) 

1 

Overall  software  effort  and  cost.  (L3-49, 
A7,  3) 

1 

Parameter  values  of  the  models  used  in 
estimating  software  effort  and  costs.  (L3- 
50,  A7,  4.1) 

i 
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CMU/SEI-94-HB-1 


L3-Process-79 


ISM  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process,  continued  from  the  previous  page. 


Output 

Org.  Outputs 

References 

Parameter  values  used  to  derive  estimates 
for  software  size,  effort,  cost,  schedule,  and 
use  of  critical  computer  resources.  (L3-46, 
A5,  2) 

Productivity  and  cost  data.  (L3-49,  A7,  2) 

Project  measurement  data.  (L3-39,  Cl,  4) 

Project's  defined  software  process.  (L3-39, 
Cl,  1) 

Project's  deviations  from  the  organization’s 
standard  software  process.  (L3-39,  Cl,  2) 

Project's  software  costs.  (L3-48,  A7) 

Project's  software  development  plan.  (L3- 
44,  A3) 

Project's  software  effort.  (L3-48,  A7) 

Project's  software  risPs.  (L3-52,  A 10) 

Rationale  for  the  contingency  (for  each 
software  element  identified  as  a  software 
risk).  (L3-48,  A6,  2.1) 

Rationales  for  similarities  and  differences 
between  the  parameter  values  (used  to 
derive  estimates  for  software  size,  effort, 
cost,  schedule,  and  use  of  critical  computer 
resources).  (L3-46,  A5,  2.2) 

Readiness  criteria  (for  key  tasks).  (L3-44, 
A4,  3) 

Reasoning  used  to  judge  the  credibility  of 
the  estimates  for  the  project’s  critical 
computer  resources.  (L3-50,  A8,  1 .3) 

Reasoning  used  to  judge  the  credibility  of 
the  project's  estimates  (for  software  size, 
effort,  cost,  schedule,  and  use  of  critical 
computer  resources).  (L3-47,  A5,  2.3) 

Replanning  data  (from  the  software 
project).  (L3-47,  A5,  3) 

Results  of  software  quality  assurance 
reviews  and/or  audits  of  software  project 
activities  and  work  products.  (L3-57,  V3) 

Reuse  measurements.  (L3-48,  A6,  3.1) 

Continued  on  next  page 


L3-Process-80 


CMU.'SEI-94-HB-1 


ISM  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process,  continued  from  the  previous  page. 


V 

Output 

C'rg.  Outputs 

References 

Risks  associated  with  reducing  or 
eliminating  the  contingency  (for  each 
software  element  identified  as  a  software 
risk).  (L3-48,  A6,  2.2) 

Schedule  critical  paths.  (L3-52,  A9,  3) 

Similarities  and  differences  between  the 
project  and  the  sources  for  historical  data 
in  terms  of  application  domain  and  design 
approach.  (L3-50,  A8,  1.2) 

Similarities  and  differences  to  the  other 
projects  in  terms  of  application  domain 
and  design  approach.  (L3-46,  A5,  2.1) 

Size  estimates.  (L3-48,  A6,  1.1) 

Size  of  changes  to  the  software  work 
products.  (L3-47,  A6) 

Size  of  the  software  work  products.  (L3- 
47,  A6) 

Size  threshold  for  each  managed  software 
element.  (L3-48,  A6,  5) 

Software  effort  and  cost  status.  (L3-49, 

A7,  4) 

Software  life  cycle.  (L3-41,  Al,  1) 

Software  planning  data  (from  the  software 
project).  (L3-47,  A5,  3) 

Software  plans  followed  in  interacting  with 
other  groups.  (L3-45,  A4,  9) 

Software  risk  management  plan.  (L3-53, 
AlO,  1) 

Software  schedule.  (L3-51,  A9,  1.1) 

Sources  and  rationale  for  estimates  (for  the 
project’s  critical  computer  resources).  (L3- 
50.  A8,  1.1) 

Staffing  plan.  (L3-45,  A4,  7) 

Staffing.  (L3-51,A9,  1) 

Threshold  criteria  for  each  critical  path. 
(L3-52.  A9,  5) 

Thresh-^ld  for  each  critical  computer 
resource.  (L3-5 1 ,  A8,  5) 
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ISM  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  integrated  software  management 
process,  continued  from  the  previous  page. 


V 

Output 

Org.  Outputs 

References 

Training  needs.  (L3-45,  A4,  8) 

Waivers  for  deviations  from  contractual 
software  process  requirements.  (L3-42, 
Al,4) 

Waivers  for  deviations  from  the 
organization's  standard  software  process. 
(L3-42,  Al,  3.1) 

Work  products  of  the  project's  defined 
software  process.  (L3-44,  A4,  2) 
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ISM  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process. 


Output 

State 

References 

Actions  needed  to 
bring  the  software 
project's  performance 
and  results  in  line 
with  the  current  and 
projected  needs  of 
the  business, 
customer,  and  end 
users 

are  determined  by  periodic  reviews 
of  the  software  project.  (L3-55, 

All) 

Actual  measured  data 
(from  the  software 
project) 

are  pro\'ided  for  storage  in  the 
organization's  software  process 
database  (L3-47,  A5,  3) 

Alternatives  for  each 
software  risk 

are  defined.  (L3-54,  A 10,  3) 

Changes  to  the 
project's  defined 
software  process 

□  are  reviewed.  (L3-43,  A2,  2) 

□  are  approved  before  they  are 
incorporated.  (L3-43,  A2,  2) 

Changes  to  the 
project's  defined 
software  process 
derived  from  changes 
proposed  f.  the 
software  project 

□  are  documented.  (L3-43,  A2, 

1.2) 

□  are  systematically  reviewed.  (L3- 
43,  A2,  1.2) 

Changes  to  the 
project's  defined 
software  process 
derived  from  lessons 
learned  from 
monit-^ring  the 
software  activities  of 
the  organization's 
projects 

□  are  docurrientad.  (L3-43,  A2, 

1.1) 

□  are  systematically  reviewed.  (L3- 
43,  A2,  1.1) 

Changes  to  the 
project's  defined 
software  process 
derived  from  process 
and  work  product 
measurement  data 

□  are  documenied.  (L3-43,  A2, 

1.3) 

□  are  systematically  reviewed.  (L3- 
43,  A2,  1.3) 

Commitments 

are  allocated  in  the  schedule 
consistent  with  the  project's  define  ' 
software  proce.ss.  (L3-5 1 ,  A9,  1 ) 
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ISM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


< 

Output 

State 

References 

Completion  criteria 

□  are  established.  (L3-44,  A4,  3) 

□  are  documented.  (L3-44,  A4,  3) 

□  are  used  to  determine  completion 
of  key  tasks.  (L3-44,  A4,  3) 

Contingency  factor 
applied  to  the  size 
estimate 

is  applied  to  the  size  estimate  for 
each  software  element  identified  as  a 
software  risk.  (L3-48,  A6,  2) 

Costs 

are  allocated  in  the  schedule 
consiste.it  with  the  project's  defined 
software  process.  (L3-51,  A9,  1) 

Criteria  for  selecting 
among  the 
alternatives  for  each 
software  risk 

are  defined.  (L3-54,  A 10,  3) 

Critical  dependencies 
(of  the  project’s 
software  schedule) 

□  are  managed  according  to  a 
documented  procedure.  (L3-51, 
A9) 

□  are  allocated  in  the  schedule 
consistent  with  the  project's 
defined  software  process.  (L3- 
51,  A9,  1) 

□  are  defined.  (L3-51,  A9,  2) 

□  are  negotiated.  (L3-51,  A9,  2) 

□  are  reflected  in  the  software 
schedule.  (L3-51,  A9,  2) 

Description  of  the 
project's  defined 
software  process 

□  is  documented.  (L3-41,  Al,  2) 

□  is  managed  and  controlled.  (L3- 
42,  Al,5) 

Documented  criteria 
to  indicate  when  to 
replar  the  software 
project 

are  defined.  (L3  45,  A4,  4) 
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ISM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Effort  and  cost 
threshold  for  each 
individually  managed 
software  task  or  stage 

□  is  established.  (L3-50,  A7,  5) 

□  requires  action  when  projected  to 
be  exceeded.  (L3-50,  A7,  5) 

Effort  to  modify  and 
incorporate  reusable 
components 

is  factored  into  the  size  estimates. 
(L3-48,  A6,  3.2) 

Estimates  for  the 
project's  critical 
computer  resources 

are  derived  based  on  historical 
experience,  simulations,  prototyping, 
or  analysis,  as  appropriate.  (L3-50, 
A8,  1) 

Factors  which  could 
significantly  affect 
the  size  of  the 
software  work 
products 

□  are  identified.  (L3-48,  A6,  4) 

□  are  monitored  closely.  (L3-48, 
A6,4) 

Information  obtained 
from  monitoring  the 
(software)  risks 

is  used  to  refine  the  risk  assessments 
and  software  risk  management  plans. 
(L3-55,  AlO,  6.2) 

Initial  release  of  the 
software  risk 
management  plan 

undergoes  peer  review.  (L3-54,  AlO, 
4) 

Lessons  learned 
(management) 

□  are  documented.  (L3-45,  A4,  5) 

□  are  stored  in  the  organization's 
library  of  software  process- 
related  documentation.  (L3-45, 
A4,  5) 

Lessons  learned 
(technical) 

□  are  documented.  (L3-45,  A4,  5) 

□  are  stored  in  the  organization's 
library  of  software  process- 
related  documentation.  (L3-45, 
A4.  5) 

Major  revisions  to  the 
software  risk 
management  plan 

undergo  peer  review.  (L3-54,  AlO, 

4) 

Measurement  data 
needed  to  manage 
the  software  project 

□  are  gathered.  (L3-44,  A4,  I) 

□  are  analyzed.  (L3-44,  A4,  1) 

□  are  reported.  (L3-44,  A4,  1) 
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ISM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


yl 

Output 

State 

References 

Measurements  (to 
determine  the 
effectiveness  of  the 
integrated  software 
management 
activities) 

□  are  made.  (L3-56,  Ml) 

□  are  used.  (L3-56,  Ml) 

Milestones 

are  allocated  in  the  schedule 
consistent  with  the  project's  defined 
software  process.  (L3-51,  A9,  1) 

Organization's 
software  process 
database 

□  is  used  for  software  planning. 
(L3-46,  A5) 

□  is  used  for  software  estimating. 
(L3-46,  A5) 

Overall  software 
effort  and  cost 

is  allocated  to  individually  managed 
tasks  or  stages  as  needed  to  manage 
the  effort  and  cost  effectively.  (L3- 
49,  A7,  3) 

Parameter  values  of 
the  models  used  in 
estimating  software 
effort  and  costs 

are  updated  whenever  major  changes 
are  made  to  the  software 
requirements.  (L3-50,  A7,  4.1) 

Parameter  values 
used  to  derive 
estimates  for  software 
size,  effort,  cost, 
schedule,  and  use  of 
critical  computer 
resources 

are  compared  to  those  of  other 
software  projects  to  assess  their 
validity.  (L3-46,  A5,  2) 

Productivity  and  cost 
data 

are  adjusted  to  incorporate  project 
variables.  (L3-49,  A7,  2) 

Project  measurement 
data 

□  are  collected  by  each  project. 
(L3-39.  Cl,  4) 

□  are  stored  by  each  project  in  the 
organization's  software  process 
database.  (L3-39,  Cl,4) 
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iSM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Project’s  defined 
software  process 

□  is  documented  by  each  project 
by  tailoring  the  organization's 
standard  software  process.  (L3- 
39,  Cl,  1) 

□  is  developed  by  tailoring  the 
organization's  standard  software 
process  according  to  a 
documented  procedure.  (L3-41. 
Al) 

□  is  revised  according  to  a 
documented  procedure.  (L3-43, 
A2) 

Project's  deviations 
from  the 
organization's 
standard  software 
process 

□  are  documented.  (L3-39,  Cl,  2) 

□  are  approved.  (L3-39,  Cl,  2) 

Project's  software 
costs 

are  managed  according  to  a 
documented  procedure.  (L3-48,  A7) 

Project's  software 
development  plan 

□  is  developed  according  to  a 
documented  procedure.  (L3-44, 
A3) 

□  is  revised  according  to  a 
documented  procedure.  (L3-44, 
A3) 

Project's  software 
effort 

is  managed  according  to  a 
documented  procedure.  (L3-48,  A7) 
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ISM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
"ontinued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Project’s  software 
risks  or  software  risks 

□  are  identified  according  to  a 
documented  procedure.  (L3-52, 
AlO) 

□  are  assessed  according  to  a 
documented  procedure.  (L3-52, 
AlO) 

□  are  documented  according  to  a 
documented  procedure.  (L3-52, 
AlO) 

□  are  managed  according  to  a 
documented  procedure.  (L3-52, 
AlO) 

□  are  tracked.  (L3-55,  AlO,  6) 

□  are  reassessed  at  selected  project 
milestones,  at  designated  risk 
checkpoints,  and  during  the 
planning  of  significant  changes 
that  affect  the  software  project. 
(L3-55,  AlO,  6) 

□  are  replanned  at  selected  project 
milestones,  at  designated  risk 
checkpoints,  and  during  the 
planning  of  significant  changes 
that  affect  the  software  project. 
(L3-55,  AlO,  6) 

Rationale  for  the 
contingency  (for 
each  software 
element  identified  as 
a  software  risk) 

is  documented.  (L3-48,  A6,  2.1) 

Rationales  for 
similarities  and 
differences  between 
the  parameter  values 
(used  to  derive 
estimates  for  software 
size,  effort,  cost, 
schedule,  and  use  of 
critical  computer 
resources) 

are  recorded.  (L3-46,  A5,  2.2) 
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ISM  Process  -  Exit  Crfteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Readiness  criteria 

□  are  established.  (L3-44,  A4,  3) 

□  are  documented.  (L3-44,  A4,  3) 

□  are  used  to  authorize  initiation  of 
key  tasks.  (L3-44,  A4,  3) 

Reasoning  used  to 
judge  the  credibility 
of  the  estimates  for 
the  project’s  critical 
computer  resources 

is  recorded.  (L3-50,  A8,  1 .3) 

Reasoning  used  to 
Judge  the  credibility 
of  the  project's 
estimates  (for 
software  size,  effort, 
cost,  schedule,  and 
use  of  critical 
computer  resources) 

is  recorded.  (L3-47,  A5,  2.3) 

Replanning  data 
(from  the  software 
project) 

are  provided  for  storage  in  the 
organization’s  software  process 
database.  (L3-47,  A5,  3) 

Reuse  measurements 

account  for  the  reuse  of 
requirements,  design,  code,  test  plan, 
and  test  procedures,  etc.  fL3-48,  A6, 
3.1) 

Risks  associated  with 
reducing  or 
eliminating  the 
contingency  (for 
each  software 
element  identified  as 
a  software  risk) 

□  are  assessed.  (L3-48,  A6,  2.2) 

□  are  documented.  (L3-48,  A6, 

2.2) 

Schedule  critical 
paths 

□  are  defined.  (L3-52,  A9,  3) 

□  are  reflected  in  the  software 
schedule.  (L3-52,  A9,  3) 
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ISM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Similarities  ^nd 
differences  between 
the  project  and  the 
sources  for  historical 
data  in  terms  of 
application  domain 
and  design  approach 

□  are  assessed.  (L3-50,  A8,  1 .2) 

□  arc  recorded.  (L3-50,  A8,  1.2) 

Similarities  and 
differences  to  the 
other  projects  in 
terms  of  application 
domain  and  design 
approach 

□  are  assessed.  (L3-46,  A5,  2.1) 

□  are  recorded.  (L3-46,  A5,  2.1) 

Size  estimates 

are  prepared  using  appropriate 
procedures  and  data.  (L3-48,  A6, 

1-1) 

Size  of  changes  to 
the  software  work 
products 

is  managed  according  to  a 
Qocumented  procedure.  (L3-47,  A6) 

Size  of  the  software 
work  products 

is  managed  according  to  a 
documented  procedure.  (L3-47,  A6) 

Size  threshold  for 
each  managed 
software  element 

□  is  established.  (L3-48,  A6,  5) 

□  requires  action  when  projected  to 
be  exceeded.  (L3-48,  A6,  5) 

Software  life  cycle 

□  is  selected  from  among  those 
approved  by  the  organization,  to 
satisfy  the  project’s  contractual 
and  operational  constraints.  (L3- 
41,  Al,  1.1) 

□  is  modified,  if  necessary,  in  ways 
permitted  by  the  organization's 
tailoring  guidelines  and  criteria. 
(L3-41,  Al,  1.2) 

□  is  documented  according  to  the 
organization’s  stanuards.  (L3-41, 
Al,  1.3) 

Software  planning 
data  (from  the 
software  project) 

are  provided  for  storage  in  the 
organization’s  software  process 
database.  (L3-47,  A5,  3) 
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ISM  Process  -  Exit  Criteria,  Continued 


Output'based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
exit  criteria,  to  exit  the  integrated  software  management  process,  continued  from  the  previous 

continued  page. 


V 

Output 

State 

References 

Software  plans 
followed  in 
interacting  with  other 
groups 

are  adjusted  to  account  for  disparities 
with  these  groups  and  for  other 
potential  problems.  (L3-45,  A4,  9) 

Software  risk 
management  plan 

□  is  documented.  (L3-53,  A 10,  1) 

□  is  used  to  identify  and  manage 
the  software  risks.  (L3-53,  AlO, 

1) 

□  is  managed  and  controlled.  (L3- 
54,  AlO,  5) 

□  is  reviewed  at  reassessment 
checkpoints  (i.e.,  at  selected 
project  milestones,  at  designated 
risk  checkpoints,  and  during  the 
planning  of  significant  changes 
that  affect  the  software  project). 
(L3-55,  AlO,  6.1) 

□  is  revised  at  reassessment 
checkpoints  (i.e.,  at  selected 
project  milestones,  at  designated 
risk  checkpoints,  and  during  the 
planning  of  significant  changes 
that  affect  the  software  project). 
(L3-55,  AlO,  6.1) 

Software  schedule 

identifies  specific  tasks  and 
milestones  whose  completion  can  be 
objectively  determined  (i.e.,  a  binary 
or  yes/no  determination).  (L3-51, 

A9,  1.1) 

Sources  and  rationale 
for  estimates  (for  the 
project’s  critical 
computer  resources) 

are  documented.  (L3-50,  A8,  1.1) 

Staffing 

is  allocated  in  the  schedule  consistent 
with  the  project's  defined  software 
process.  (L3-51,  A9,  1) 

Stafiing  plan 

addresses  the  software  project's  needs 
for  individuals  with  special  skills  and 
application  domain  knowledge.  (L3- 
45,  A4,  7) 
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ISM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  Exit 
Criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  integrated  software  management  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Threshold  criteria  for 
each  critical  path 

□  are  documented.  (L3-52,  A9,  5) 

□  are  established.  (L3-52,  A9,  5) 

□  require  action  when  projected  to 
be  exceeded.  (L3-52,  A9,  5) 

Threshold  for  each 
critical  computer 
resource 

□  is  established.  (L3-51,  A8,  5) 

□  requires  action  when  projected  to 
be  exceeded.  (L3-51,  A8,  5) 

Training  needs 

□  are  identified.  (L3-45,  A4,  8) 

□  are  documented  to  fit  the  specific 
needs  of  the  software  project. 
(L3-45,  A4,  8) 

Waivers  for 
deviations  from 
contractual  software 
process  requirements 

□  are  documented.  (L3-42,  Al,4> 

Q  are  reviewed  by  senior 

management  and  the  software 
project’s  customer,  as 
appropriate.  (L3-42,  Al,4) 

□  are  approved  by  senior 
management  and  the  software 
project’s  customer,  as 
appropriate.  (L3-42,  Al,  4) 

Waivers  for 
deviations  from  the 
organization's 
standard  softwaie 
process 

□  are  documented.  (L3-42,  Al, 

3.1) 

□  are  reviewed  by  senior 
management.  (L3-42,  Al,  3.1) 

□  are  approved  by  senior 
management.  (L3-42,  Al,  3.1) 

Work  products  of  the 
project's  defined 
software  process 

are  tied  to  the  software  estimating, 
planning,  and  tracking  activities. 
(L3-44,  A4,  2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  integrated  software  management  process. 


Condition 

References 

Each  project  performs  its  software  activities  in  accordance 
with  the  project’s  defined  software  process.  (L3-39,  Cl,  3) 
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ISM  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  table  below  describes  the  conditions  that  must  be  satisfied  in  order  to  exit  the 
integrated  software  management  process,  continued  from  the  previous  page. 


Condition 

References 

The  project's  defined  software  process  is  developed  by 
tailoring  the  organization’s  standard  software  process 
according  to  a  documented  procedure.  (L3-41,  Al) 

Tailoring  of  the  organization’s  standard  software  process  for 
the  project  is  reviewed  by  the  group  responsible  for 
coordinating  the  organization's  software  process  activities 
(e.g.,  software  engineering  process  group)  and  approved 
by  senior  management.  (L3-42,  Al,  3) 

The  software  project  is  managed  in  accordance  with  the 
project’s  defined  software  process.  (L3-44,  A4) 

Technical  and  management  lessons  learned  from  monitoring 
the  activities  of  other  projects  in  the  organization  are 
systematically  reviewed  and  used  to  estimate,  plan,  track,  and 
replan  the  software  project.  (L3-45,  A4,  6) 

The  organization’s  software  process  database  is  used  as  a 
source  of  data  to  estimate,  plan,  track,  and  replan  a  software 
project;  data  for  similar  software  projects  are  used  when 
possible.  (L3-46,  A5,  1) 

When  the  software  effort  and  cost  status  is  reviewed  and  the 
estimates  are  revised,  actual  expenditures  over  time  and 
against  work  completed  are  compared  to  the  software 
development  plan  and  used  to  refine  the  effort  and  cost 
estimates  for  remaining  work.  (L3-49,  Al,  4) 

Actual  data  on  project  productivity  and  other  new  software 
costs  are  used  where  appropriate.  (L3-50,  Al,  4.2) 

The  project’s  critical  computer  resources  are  managed 
according  to  a  documented  procedure.  (L3-50,  A8) 

The  planned  computer  resources,  the  system  requirements 
allocated  to  software,  the  software  requirements,  and/or  the 
software  design  are  adjusted  to  achieve  the  project’s  critical 
computer  resource  requirements.  (L3-50,  A8,  2) 

The  available  computer  resources  are  allocated  to  the 
software  components.  (L3-50,  A8,  3) 

The  critical  dependencies  and  critical  paths  of  the  project’s 
software  schedule  are  managed  according  to  a  documented 
procedure.  (L3-51,  A9) 

The  software  project's  critical  dependencies  and  schedule 
critical  paths  are  tracked  on  a  regular  basis..  (L3-52,  A9,  4) 

Contingency  planning  is  based  on  the  project’s  defined 
software  process  and  is  performed  throughout  the  project’s 
.software  life  cycle.  (l3-54,  A 10,  2) 
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ISM  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  table  below  describes  the  conditions  that  must  be  satisfied  in  order  to  exit  the 
integrated  software  management  process,  continued  from  the  previous  page. 


V 

Condition 

References 

i 

The  software  engineering  group  and  other  affected  groups 
and  individuals  are  included  in  the  communications  on  the 
software  risks,  the  software  risk  management  plans,  and  the 
results  of  risk  mitigation.  (L3-55,  A 10,  7) 

r 

Reviews  of  the  software  project  are  periodically  performed 
to  determine  the  actions  needed  to  bring  the  software 
project's  performance  and  results  in  line  with  the  current  and 
projected  needs  of  the  business,  customer,  and  end  users,  as 
appropriate.  (L3-55,  All) 

The  activities  for  managing  the  software  project  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L3-56,  VI) 

The  activities  for  managing  the  software  project  are  reviewed 
with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-57,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  managing  the  software 
project  and  reports  the  results.  (L3-57,  V3) 
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ISM  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  integrated 
software  management  process. 


Review  or  Audit 

Review 

Participants 

References 

Tailoring  of  the  organization's  standard 
software  process  for  the  project  is  reviewed 

by  the  group  responsible  for  coordinating 
the  organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  and  approved  by  senior 
management.  (L3-42,  Al,3) 

Group 

responsible  for 

coordinating 

the 

organization's 

software 

process 

activities 

Senior 

management 

Waivers  for  deviations  from  the 
organization's  standard  software  process 
are  documented  and  are  reviewed  and 
approved  by  senior  management.  (L3-42, 
Al,  3.1) 

Senior 

management 

Waivers  for  deviations  from  contractual 
software  process  requirements  are 
documented  and  are  reviewed  and 
approved  by  senior  management  and  the 
software  project's  customer,  as  appropriate. 
(L3-42,  Al,  4) 

Senior 

manageuient 

Customer 

Changes  derived  from  the  following  are 

documented  and  systematically  reviewed: 

(L3-43,  A2,  1) 

□  Lessons  learned  from  monitoring  the 
software  activities  of  the  organization's 
projects. 

□  Changes  proposed  by  the  software 
project. 

□  Process  and  work  product 
measurement  data. 

Not  specified  in 
theCMM 

Changes  to  the  project's  defined  software 
process  are  reviewed  and  approved  before 
they  are  incorporated.  (L3-43,  A2,  2) 

Not  specified  in 
the  CMM 

Technical  and  management  lessons  learned 
from  monitoring  the  activities  of  other 
projects  in  the  organization  are 
systematically  reviewed  and  ii.sed  to 
estimate,  plan,  track,  and  replan  the 
software  project.  (L3-45,  A4,  6) 

Not  specified  in 
the  CMM 
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ISM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  integrated 
software  management  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

A  group  that  is  independent  of  the 
software  engineering  group  reviews  the 
procedures  for  estimating  the  size  of  the 
software  work  products,  and  provides 
guidance  in  using  historical  data  from  the 
organization  s  softv  are  process  database  to 
establish  credible  es  imates.  (L3-47,  A6,  1 ) 

Group  that  is 
independent  of 
the  software 
engineering 
group 

When  the  validity  of  a  s<z-  “SMniate  is 
questioned,  a  team  r  "  peers  and  '  •'••♦s 

reviews  the  e-'timat' .  (1  3-48.  .V6,  1.2) 

Team  of  peers 
and  experts 

When  the  software  ef 'tatusis 
reviewed  and  the  estimates  •d;c,  vevised, 
actual  pv'icnditure.''  over  time  and  against 
work  completed  are  '  '-mpared  to  the 
software  developm  an  and  used  to 

lelu.e  ;ne  effort  <>•  '' -t  estimates  for 

ret  ,  <mng  work.  (L3-49,  A7,  4) 

Not  specified  in 
the  CMM 

Tl  i  initial  release  .."‘d  .  lajor  revisions  to 
t'.e  software  risk  n'-gement  plan 
■;nde''eo  peer  revi.”  i'.?  1,  AK ,  4) 

Not  specified  in 
the  CMM 

.  SI.  priorities  an>.  .icft'  '  * 

management  plans  are  revi  A^ed  and 
revised  at  the.se  reassessmei’  points  (i.e.,  at 
selected  project  milestones,  at  designated 
risk  checkpoints,  and  during  the  planning 
of  significant  changes  that  affect  the 
software  project).  (L3-55,  AlO,  6.n 

Not  specified  in 
the  CMM 

Reviews  of  the  software  project  are 
periodically  performed  to  determine  the 
actions  needed  to  bring  the  software 
project's  perfc  ■-  nee  and  results  in  line 
with  the  current  and  projected  needs  of  the 
business,  customer,  and  end  users,  as 
appropriate.  (L3-55,  All) 

Not  specified  in 
the  CMM 

The  activities  for  managing  the  software 
project  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L3-56, 
VI) 

Senior 

management 

The  activities  for  managing  the  software 
project  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-57,  V2) 

Project 

manager 
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ISM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  integrated 
software  management  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  managing  the  software  project 
and  reports  the  results.  (L3-57,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify: 

□  The  process  for  developing  and 
revising  the  project's  defined  software 
process. 

□  The  process  for  preparing  the  project's 
software  development  plan  and 
software  risk  management  plan. 

□  The  processes  for  managing  the  project 
in  accordance  with  the  project's  defined 
software  process. 

□  The  processes  for  collecting  and 
providing  appropriate  data  to  the 
organization's  software  process 
database. 

□  The  process  for  using  the 
organization's  software  process 
database  to  supp-  rt  the  software 
project's  planning,  estimating,  and 
tracking  activities. 

SQA  group 
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ISM  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  integrated  software  management  process. 


V 

Work  Products  Managed  and  Controlled 

References 

Description  of  the  project's  defined  software  process.  (L3- 
42,  AI,  5) 

Software  risk  management  plan.  (L3-54,  A 10,  5)  i 
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ISM  Process  -  Measurements 


Measurements 


The  table  below  lists  the  recommended  measurements  for  the  integrated  software 
management  process. 


V 

Measurements 

References 

Project  measurement  data.  (L3-39,  Cl,  4) 

Process  and  work  product  measurement  data.  (L3-43,  A2, 
1.3) 

Measurement  data  needed  to  manage  the  software  project. 
(L3-44,  A4,  1) 

Software  planning  data,  replanning  data,  and  actual 
measured  data.  (L3-47,  A5,  3) 

Reuse  measurements  (reuse  of  requirements,  design,  code, 
test  plan,  and  test  procedures,  etc.).  (L3-48,  A6,  3.1) 

Measurements  to  determine  the  effectiveness  of  the 

integrated  software  management  activities.  (L3-56,  Ml) 

Examples  of  measurements  include: 

□  Effort  expended  over  time  to  manage  the  software 
project,  compared  to  the  plan. 

□  Frequency,  causes,  and  magnitude  of  replanning  effort. 

□  For  each  identified  software  risk,  the  realized  adverse 
impact  compared  to  the  estimated  loss. 

□  The  number  and  magnitude  of  unanticipated  major 
adverse  impacts  to  the  software  project,  tracked  over 
time. 
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ISM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  integrated  software  management  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


V 

Documented  Procedure(s) 

References 

The  project's  defined  software  process  is  developed  by 
tailoring  the  organization's  standard  software  process 
according  to  a  documented  procedure.  (L3-41,  Al) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Each  project's  defined  software  process  is  revised  according 
to  a  documented  procedure.  (L3-43,  A2) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  development  plan,  which  describes  the 
use  of  the  project's  defined  software  process,  is  developed 
and  revii..cd  .  .  tc  •  documented  procedure.  (L3-44, 

A3) 

The  size  • ,.  software  work  products  (or  size  of  changes  to 

tiic  sofiv>.  Aork  products)  is  managed  according  to  a 
documeniec  procedure.  (L3-47,  A6) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  effort  and  costs  are  managed 
according  to  a  documented  procedure.  (L3-48,  A7) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  critical  computer  resources  are  managed 
according  to  a  documented  procedure.  (L3-50,  A8) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  critical  dependencies  and  critical  paths  of  the  project's 
software  schedule  are  managed  according  to  a  documented 
procedure.  (L3-51,  A9) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

The  project's  software  risks  are  identified,  assessed, 
documented,  and  managed  according  to  a  documented 
procedure.  (L3-52,  AlO) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

L3-Process-100 


CMU/SEI-94-HB-1 


ISM  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  integrated  software 
management  process. 


V 

Training 

References 

The  individuals  responsible  for  developing  the  project's 
defined  software  process  receive  required  training  in  how  to 
tailor  the  organization's  standard  software  process  and  use 
the  related  process  assets.  (L3-39,  Ab2) 

The  software  managers  receive  required  training  in 
managing  the  technical,  administrative,  and  personnel 
aspects  of  the  software  project  based  on  the  project's  defined 
software  process.  (L3-40,  Ab3) 
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Tools 


The  table  below  lists  the  tools  recommended  for  the  integrated  software 
management  process. 


Tools 

References 

Organization's  software  process  database.  (L3-39,  Cl,4) 
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Software  Product  Engineering  (SPE)  Process 
SPE  Process  -  Overview 


SPE  process 
purpose 


SPE  process 
description 


The  purpose  of  Software  Product  Engineering  is  to  consistently  perform  a  well- 
defined  engineering  process  that  integrates  all  the  software  engineering  activities  to 
produce  correct,  consistent  software  products  effectively  and  efficiently.  (L3-59) 


Software  Product  Engineering  involves  performing  the  engineering  tasks  to  build 
and  maintain  the  software  using  the  project's  defined  software  process  (which  is 
described  in  the  Integrated  Software  Management  key  process  area)  and 
appropriate  methods  and  tools. 

The  software  engineering  tasks  include  analyzing  the  system  requirements 
allocated  to  software  (these  system  requirements  are  described  in  the  Requirements 
Management  key  process  area),  developing  the  software  requirements,  developing 
the  software  architecture,  designing  the  software,  implementing  the  software  in  the 
code,  integrating  the  software  components,  and  testing  the  software  to  verify  that  it 
satisfies  the  specified  requirements  (i.e.,  the  system  requirements  allocated  to 
software  and  the  software  requirements). 

Documentation  needed  to  perform  the  software  engineering  tasks  (e.g.,  software 
requirements  document,  software  design  document,  test  plan,  and  test  procedures) 
is  developed  and  reviewed  to  ensure  that  each  task  addresses  the  results  of 
predecessor  tasks  and  the  results  produced  are  appropriate  for  the  subsequent  tasks 
including  the  tasks  of  operating  and  maintaining  the  software).  When  changes  are 
approved,  affected  software  work  products,  plans,  commitments,  processes,  and 
activities  are  revised  to  reflect  the  approved  changes.  (L3-59) 
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SPE  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-105 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-l  10 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-l  12 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-l  14 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-123 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-126 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L3-Process-140 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-144 

Measurements 

Description  of  process  measurements. 

L3-Process-145 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-146 

Training 

List  of  training. 

L3-Process-147 

Tools 

List  of  tools. 

L3-Process-148 
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SPE  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  product  engineering  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

Changes  (to  the  software  work  products, 
plans,  process  descriptions,  and  activities) 
are  negotiated  with  and  communicated  to 
the  affected  groups.  (L3-79,  AlO,  4.4) 

Customer 

□  The  software  requirements  document  is 
reviewed  with  the  customer  and  end 
users,  as  appropriate.  (L3-68,  A2,  10) 

□  Testing  criteria  are  developed  and 
reviewed  with  the  customer  and  the  end 
users,  as  appropriate.  (L3-72,  A5,  1) 

□  System  and  acceptance  testing  are 
documented  in  a  test  plan,  which  is 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as  appropriate. 
(L3-75,  A7,  2) 

□  The  test  cases  are  documented  and  are 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as  appropriate, 
before  the  testing  begins.  (L3-76,  A7, 

4) 

□  Preliminary  versions  of  the 
documentation  are  developed  and 
made  available  early  in  the  software  life 
cycle  for  the  customer,  end  users,  and 
software  maintainers,  as  appropriate,  to 
review  and  provide  feedback.  (L3-77, 
A8,  3) 

□  The  final  documentation  is  reviewed 
and  approved  by  the  customer,  end 
users,  and  software  maintainers,  as 
appropriate.  (L3-77,  A8,  7) 

Documenta¬ 
tion  specialist 

Documentation  specialists  actively 
participate  in  planning,  developing,  and 
maintaining  documentation.  (L3-77,  A8, 

2) 

Continued  on  next  page 
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Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  product  engineering  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

End  users 

□  The  software  requirements  document  is 
reviewed  with  the  customer  and  end 
users,  as  appropriate.  (L3-68,  A2,  10) 

□  Testing  criteria  are  developed  and 
reviewed  with  the  customer  and  the  end 
users,  as  appropriate.  (L3-72,  A5,  1) 

□  System  and  acceptance  testing  are 
documented  in  a  test  plan,  which  is 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as  appropriate. 
(L3-75,  A7,  2) 

□  The  test  cases  are  documented  and  are 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as  appropriate, 
before  the  testing  begins.  (L3-76,  A7, 

4) 

□  Preliminary  versions  of  the 
documentation  are  developed  and 
made  available  early  in  the  software  life 
cycle  for  the  customer,  end  users,  and 
software  maintainers,  as  appropriate,  to 
review  and  provide  feedback.  (L3-77, 
A8,  3) 

□  The  final  documentation  is  reviewed 
and  approved  by  the  customer,  end 
users,  and  software  maintainers,  as 
appropriate.  (L3-77,  A8,  7) 

Group 

responsible  for 
the  system 
requirements 

Problems  with  the  software  requirements 
are  identified  and  reviewed  with  the  group 
responsible  for  the  system  requirements; 
appropriate  changes  are  made  to  the 
allocated  requirements  and  to  the  software 
requirements.  (L3-67,  A2,  4.1) 

Group 

responsible  for 
system  and 
acceptance 
testing 

The  group  responsible  for  system  and 
acceptance  testing  of  the  software  analyzes 
each  software  requirement  to  verify  it  can 
be  tested.  (L3-67,  A2,  6) 

Continued  on  next  page 
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Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  product  engineering  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Individuals 

Skilled  individuals  are  available  to  perform 
the  different  software  engineering  tasks, 
including:  (L3-61,  Abl,  1) 

□  software  requirements  analysis, 

□  software  design, 

□  coding, 

□  testing,  and 

□  software  maintenance. 

Individuals 
involved  in 
coding 

The  individuals  involved  in  coding  review 
the  software  requirements  and  software 
design  to  ensure  that  issues  affecting  the 
coding  are  identified  and  resolved.  (L3-71, 
A4,  I) 

Individuals 
involved  in 
developing  the 
software 
requirements 

The  individuals  involved  in  developing  the 
software  requirements  review  the  allocated 
requirements  to  ensure  that  issues  affecting 
the  software  requirerr''..its  analysis  are 
identified  and  resolved.  (L3-66,  A2,  1) 

Individuals 
involved  in 
software 
design 

The  individuals  involved  in  the  software 
design  review  the  software  requirements  to 
ensure  that  issues  affecting  the  software 
design  are  identified  and  resolved.  (L3-69, 
A3,  2) 

Individuals 
responsible  for 
system  and 
acceptance 
testing 

The  integration  test  cases  and  test 
procedures  are  reviewed  with  the 
individuals  responsible  for  the  software 
requirements,  software  design,  and  system 
and  acceptance  testing.  (L3-75,  A6,  2) 

Individuals 
responsible  for 
the  software 
design 

The  integration  test  cases  and  test 
procedures  are  reviewed  with  the 
individuals  responsible  for  the  software 
requirements,  software  design,  and  system 
and  acceptance  testing.  (L3-75,  A6,  2) 

Individuals 
responsible  for 
the  software 
requirements 

The  integration  test  cases  and  test 
procedures  are  reviewed  with  the 
individuals  responsible  for  the  software 
requirements,  software  design,  and  system 
and  acceptance  testing.  (L3-75,  A6,  2) 

1 
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Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  product  engineering  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Project 

manager 

□  The  project  manager  and  all  software 
managers  receive  orientation  in  the 
technical  aspects  of  the  software 
project.  (L3-64,  Ab4) 

□  The  activities  for  software  product 
engineering  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  basis.  (L3-80,  V2) 

Senior 

management 

The  activities  for  software  product 
engineering  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L3-80, 
VI) 

Software 
engineering 
technical  staff 

□  Members  of  the  software  engineering 
technical  staff  receive  required  training 
to  perform  their  technical  assignments. 
(L3-63,  Ab2) 

□  Members  of  the  software  engineering 
technical  staff  receive  orientation  in 
related  software  engineering 
disciplines.  (L3-64,  Ab3) 

Software 

maintainer 

□  Preliminary  versions  of  the 
documentation  are  developed  and 
made  available  early  in  the  software  life 
cycle  for  the  customer,  end  users,  and 
software  maintainers,  as  appropriate,  to 
review  and  provide  feedback.  (L3-77, 
A8,  3) 

□  The  final  documentation  is  reviewed 
and  approved  by  the  customer,  end 
users,  and  software  maintainers,  as 
appropriate.  (L3-77,  A8,  7) 

Software 

manager 

The  project  manager  and  all  software 
managers  receive  orientation  in  the 
technical  aspects  of  the  software  project. 
(L3-64,  Ab4) 

Continued  on  next  page 
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Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  product  engineering  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  product  engineering 
and  reports  the  results.  (L3-81,  V3) 

_ I 

Test  group 

The  test  cases  and  test  procedures  are 
planned  and  prepared  by  a  test  group  that 
is  independent  of  the  software  developers. 
(L3-76,  A7,  3) 
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Input-based 
entry  criteria 


Generai  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  software  product  engineering  process. 


V 

Input 

State 

References 

Changes  to  allocated 
requirements 

□  are  approved.  (L3-79,  A 10,  4.2) 

□  are  incorporated  before  any 
software  work  products  or 
activities  are  changed.  (L3-79, 

A 10,  4.2) 

Changes  to  software 
process  descriptions 

are  proposed.  (L3-78,  AlO,  4) 

Changes  to  software 
activities 

are  proposed.  'L3-78,  AlO,  4) 

Changes  to  software 
plans 

are  proposed.  (L3-78,  AlO,  4) 

Changes  to  software 
work  products 

are  proposed.  (L3-78,  AlO,  4) 

Test  plan 

is  documented.  (L3-81,  V3,  5) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  product  engineering  process. 


Condition 

References 

The  project  follows  a  written  organizational  policy  for 
performing  the  software  engineering  activities.  (L3-60,  Cl) 

Adequate  resources  and  funding  are  provided  for 
performing  the  software  engineering  tasks.  (L3-61,  Abl) 

Skilled  individuals  are  available  to  perform  the  different 
software  engineering  tasks,  including:  (L3-61,  Abl,  1) 

□  software  requirements  analysis, 

□  software  design, 

□  coding, 

□  testing,  and 

□  software  maintenance. 

Tools  to  support  the  software  engineering  tasks  are  made 
available.  (L3-61,  Abl,  2) 

Continued  on  next  page 
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SPE  Process  -  Entry  Criteria,  continued 


General  entry 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  product  engineering  process,  continued  from  the 
previous  page. 


nr 

Condition 

References 

Members  of  the  software  engineering  technical  staff  receive 
required  training  to  perform  their  technical  assignments. 
(L3-63,  Ab2) 

Members  of  the  software  engineering  technical  staff  receive 
orientation  in  related  software  engineering  disciplines.  (L3- 
64,  Ab3) 

The  project  manager  and  all  software  managers  receive 
orientation  in  the  technical  aspects  of  the  software  project. 
(L3-64,  Ab4) 
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Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  product  engineering 
process. 


V 

Input 

Org.  Input 

References 

Allocated  requirements.  (L3-66,  A2,  1) 

Application  standards.  (L3-70,  A3,  3) 

Baselined  documentation  of  the  allocated 
requirements.  (L3-76,  A7,  5) 

Baselined  software.  (L3-76,  A7,  5) 

Changes  to  allocated  requirements.  (L3- 
69,  A2.  12) 

Changes  to  code  being  tested.  (L3-74,  A5, 
8) 

Changes  to  process  descriptions.  (L3-78, 
AlO,  4) 

Changes  to  software  activities.  (L3-78, 

AlO,  4) 

Changes  to  software  design.  (L3-72,  A4, 

6) 

Changes  to  software  plans.  (L3-78,  AlO, 

4) 

Changes  to  software  products.  (L3-79, 

AlO,  4.3) 

Changes  to  software  requirements.  (L3-71, 
A3,  11) 

Changes  to  software  work  products.  (L3' 
78,  AlO,  4) 

Completion  criteria  for  each  software 
engineering  task.  (L3-81,  V3,  2) 

Methods  for  programming.  (L3-71,  A4,  2) 

Methods  for  requirements  analysis.  (L3- 
67,  A2,  2) 

Methods  for  software  design.  (L3-70,  A.), 
4) 

Methods  for  software  engineering.  (L3-65, 
Al) 

Methods  for  software  test.  (L3-72,  A5,  2) 

Needs  of  the  customer.  (L3-72,  A4,  3) 

Needs  of  the  end  users.  (L3-72,  A4,  3) 
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Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  software  product  engineering 
process,  continued  from  the  previous  page. 


Input 

Org.  Inputs 

References 

Plan  (that  accounts  for  factors  such  as 
criticality,  difficulty,  integration  and  test 
issues,  and  needs  of  the  customer  and  end 
users,  as  appropriate).  (L3-72,  A4,  3) 

Process  descriptions.  (L3-78,  AlO) 

Project’s  defined  software  process.  (L3- 
60,  Cl) 

Readiness  criteria  for  each  software 
engineering  task.  (L3-81,  V3,  2) 

Software  baseline.  (L3-82,  V3,  10) 

Software  baselined  for  software  acceptance 
testing.  (L3-77,  A8,  4) 

Software  code.  (L3-78,  AlO) 

Softw-are  design  document.  (L3-75,  A6,  3) 

Software  design.  (L3-71,  A4) 

Software  development  plan.  (L3-75,  A6, 

1) 

Software  engineering  tools.  (L3-65,  Al) 

Software  plans.  (L3-78,  AlO) 

Software  requirements  document.  (L3-75, 
A6,  3) 

Software  requirements.  (L3-66,  A2) 

Software  standards.  (L3-81,  V3,  3) 

Software  work  products.  (L3-78,  AlO) 

System  requirements  allocated  to  software. 
(L3-60,  Cl,  3) 

Test  cases.  (L3-78,  AlO,  2) 

Test  plans.  (L3-78,  AlO) 

Test  procedures.  (L3-78,  AlO) 
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Activities 


The  table  below  lists  the  recommended  activities  for  the  software  product 
engineerii  g  process. 


V 

Activities 

References 

Appropriate  software  engineering  methods  and  tools  are 
integrated  into  the  project's  defined  software  process.  (L3- 
65,  Al) 

□  The  software  engineering  tasks  are  integrated  according 
to  the  project's  defined  software  process. 

□  Methods  and  tools  appropriate  for  use  on  the  software 
project  are  selected. 

□  The  rationale  for  selecting  a  particular  tool  or 
method  is  documented. 

□  Configuration  management  models  appropriate  to  the 
software  project  are  selected  and  used. 

□  The  tools  used  to  develop  and  maintain  the  software 
products  are  placed  under  configuration  management. 

Continued  on  next  page 
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Activities,  The  table  below  lists  the  recommended  activities  for  the  software  product 

continued  engineering  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  software  requirements  are  developed,  maintained, 

documented,  and  verified  by  systematically  analyzing  the 

allocated  requirements  according  to  the  project's  defined 

software  process.  (L3-66,  A2) 

□  The  individuals  involved  in  developing  the  software 
requirements  review  the  allocated  requirements  to 
ensure  that  issues  affecting  the  software  requirements 
analysis  are  identified  and  resolved. 

□  Effective  methods  for  requirements  analysis  are  used  to 
identify  and  derive  the  software  requirements. 

□  The  results  of  the  requirements  analysis  and  the  rationale 
for  the  selected  alternative  are  documented. 

□  The  software  requirements  are  analyzed  to  ensure  they 
are  feasible  and  appropriate  to  implement  in  software, 
clearly  stated,  consistent  with  each  other,  testable,  and 
complete  (when  considered  as  a  set). 

□  Problems  with  the  software  requirements  are 

identified  and  reviewed  with  the  group  responsible 
for  the  system  requirements;  appropriate  changes 
are  made  to  the  allocated  requirements  and  to  the 
software  requirements. 

□  The  software  requirements  are  documented. 

□  The  group  responsible  for  system  and  acceptance 
testing  of  the  software  analyzes  each  software 
requirement  to  verify  it  can  be  tested. 

□  The  methods  for  verifying  and  validating  that  each 
software  requirement  is  satisfied  are  identified  and 
documented. 

□  The  software  requirements  document  undergoes  peer 
review  before  it  is  considered  complete. 

□  The  software  requirements  document  is  reviewed  and 
approved. 

□  The  software  requirements  document  is  reviewed  with 
the  customer  and  end  users,  as  appropriate. 

□  The  software  requirements  document  is  placed  under 
configuration  management. 

□  The  software  requirements  are  appropriately  changed 
whenever  the  allocated  requirements  change. 

Continued  on  next  page 
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Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  software  design  is  developed,  maintained,  documented, 

and  verified,  according  to  the  project's  defined  software 

process,  to  accommodate  the  software  requirements  and  to 

form  the  framework  for  coding.,  (L3-69,  A3) 

□  Design  criteria  are  developed  and  reviewed. 

□  The  individuals  involved  in  the  software  design  review 
the  software  requirements  to  ensure  that  issues  affecting 
the  software  design  are  identified  and  resolved. 

□  Application  standards  are  used  where  appropriate. 

□  Effective  methods  are  used  to  design  the  software. 

□  The  software  architecture  is  developed  early,  within  the 
constraints  of  the  software  life  cycle  and  technology 
being  used. 

□  The  software  architecture  is  reviewed  to  ensure  that 
architecture  issues  affecting  the  software  detailed  design 
are  identified  and  resolved. 

□  The  software  detailed  design  is  developed  based  on  the 
software  architecture. 

□  The  software  design  (i.e.,  the  software  architecture  and 
detailed  design)  is  documented. 

□  The  documentation  of  the  software  design  covers  the 
software  components;  the  internal  interfaces  between 
software  components;  and  the  software  interfaces  to 
other  software  systems,  to  hardware,  and  to  other 
system  components  (e.g.,  humans). 

□  The  software  design  document  undergoes  peer  review 
before  the  design  is  considered  complete. 

□  The  software  design  document  is  placed  under 
configuration  management. 

□  The  software  design  document  is  appropriately  changed 
whenever  the  software  requirements  change. 
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Activities, 

continued 


The  table  belov'  lists  the  recommended  activities  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


Activities 

References 

The  software  code  is  developed,  maintained,  documented, 
and  verified,  according  to  the  project's  defined  software 
process,  to  implement  the  software  requirements  and 
software  design.  (L3-71,  A4) 

□  The  individuals  involved  in  coding  review  the  software 
requirements  and  software  design  to  ensure  that  issues 
affecting  the  coding  are  identified  and  resolved. 

□  Effective  programming  methods  are  used  to  code  the 
software. 

□  The  sequence  in  which  code  units  are  developed  is  based 
on  a  plan  that  accounts  for  factors  such  as  criticality, 
difficulty,  integration  and  test  issues,  and  needs  of  the 
customer  and  end  users,  as  appropriate. 

□  Each  code  unit  undergoes  peer  review  and  is  unit  tested 
before  the  unit  is  considered  complete. 

□  The  code  is  placed  under  configuration  management. 

□  The  code  is  appropriately  changed  whenever  the 
software  requirements  or  software  design  changes. 
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Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


Activities 

References 

Software  testing  is  performed  according  to  the  project's 
defined  software  process.  (L3-72,  A5) 

□  Testing  criteria  are  developed  and  reviewed  with  the 
customer  and  the  end  users,  as  appropriate. 

□  Effective  methods  are  used  to  test  the  software. 

□  The  adequacy  of  testing  is  determined  based  on: 

□  the  level  of  testing  performed, 

□  the  test  strategy  selected,  and 

□  the  test  coverage  to  be  achieved. 

□  For  each  level  of  software  testing,  test  readiness  criteria 
are  established  and  used. 

□  Regression  testing  is  performed,  as  appropriate,  at  each 
test  level  whenever  the  software  being  tested  or  its 
environment  changes. 

□  The  test  plan,  test  procedures,  and  test  cases  undergo 
peer  review  before  they  are  considered  ready  for  use. 

□  The  test  plans,  test  procedures,  and  test  cases  are 
managed  and  controlled. 

□  Test  plans,  test  procedures,  and  test  cases  are 
appropriately  changed  whenever  the  allocated 
requirements,  software  requirements,  software  design,  or 
code  being  tested  changes. 

Integration  testing  of  the  software  is  planned  and  performed 
according  to  the  project's  defined  software  process.  (L3-74, 
A6) 

□  The  plans  for  integration  testing  are  documented  and 
based  on  the  software  development  plan. 

□  The  integration  test  cases  and  test  procedures  are 
reviewed  with  the  individuals  responsible  for  the 
software  requirements,  software  design,  and  system  and 
acceptance  testing. 

□  Integration  testing  of  the  software  is  perfoimed  against 
the  designated  version  of  the  software  requirements 
document  and  the  software  design  document. 
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Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


Activities 

References 

System  and  acceptance  testing  of  the  software  are  planned 

and  performed  to  demonstrate  that  the  software  satisfies  its 

requirements.  (L3-75,  A7) 

□  Resources  for  testing  the  software  are  assigned  early 
enough  to  provide  for  adequate  test  preparation. 

□  System  and  acceptance  testing  are  documented  in  a  test 
plan,  which  is  reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as  appropriate. 

□  The  test  cases  and  test  procedures  are  planned  and 
prepared  by  a  test  group  that  is  independent  of  the 
software  developers. 

□  The  test  cases  are  documented  and  are  reviewed  with, 
and  approved  by,  the  customer  and  end  users,  as 
appropriate,  before  the  testing  begins. 

□  Testing  of  the  software  is  performed  against  baselined 
software  and  the  ba.selined  documentation  of  the 
allocated  requirements  and  the  software  requirements. 

□  Problems  identified  during  testing  are  documented  and 
tracked  to  closure. 

□  Test  results  are  documented  and  used  as  the  basis  for 
determining  whether  the  software  satisfies  its 
requirements. 

□  The  test  results  are  managed  and  controlled. 

Continued  on  next  page 
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SPE  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


Activities 

References 

The  documentation  that  will  be  used  to  operate  and  maintain 

the  software  is  developed  and  maintained  according  to  the 

project's  defined  software  process.  (L3-76,  A8) 

□  Appropriate  methods  and  tools  are  used  to  develop  the 
documentation. 

□  Documentation  specialists  actively  participate  in 
planning,  developing,  and  maintaining  documentation. 

□  Preliminary  versions  of  the  documentation  are 
developed  and  made  available  early  in  the  software  life 
cycle  for  the  customer,  end  users,  and  software 
maintainers,  as  appropriate,  to  review  and  provide 
feedback. 

□  Final  versions  of  the  documentation  are  verified  against 
the  software  baselined  for  software  acceptance  testing. 

□  The  documentation  undergoes  peer  review. 

□  The  documentation  'a  managed  and  controlled. 

□  The  final  documentation  is  reviewed  and  approved  by 
the  customer,  end  users,  and  software  maintainers,  as 
appropriate. 

Data  on  defects  identified  in  peer  reviews  and  testing  are 
collected  and  analyzed  according  '.j  the  project's  defined 
software  process.  (L3-78,  A9) 

Continued  on  next  page 
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SPE  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


V 

Activities 

References 

Consistency  is  maintained  across  software  work  products, 
including  the  software  plans,  process  descriptions,  allocated 
requirements,  software  requirements,  software  design,  code, 
test  plans,  and  test  procedures.  (L3-78,  A 10) 

□  Software  work  products  are  documented,  and  the 
documentation  is  readily  available. 

□  The  software  requirements,  design,  code,  and  test  cases 
are  traced  to  the  source  from  which  they  were  derived 
and  to  the  products  of  the  subsequent  software 
engineering  activities. 

□  The  documentation  tracing  the  allocated  requirements 
through  the  software  requirements,  design,  code,  and  test 
cases  is  managed  and  controlled. 

□  As  understanding  of  the  software  improves,  changes  to 
the  software  work  products,  plans,  process  descriptions, 
and  activities  are  proposed,  analyzed,  and  incorporated 
as  appropriate. 

□  The  project  determines  the  impact  of  the  change 
before  the  change  is  made. 

□  Where  changes  to  the  allocated  requirements  are 
needed,  they  are  approved  and  incorporated  before 
any  software  work  products  or  activities  are  changed. 

□  Changes  to  all  software  products,  plans,  process 
descriptions,  and  activities  are  coordinated. 

□  Changes  are  negotiated  with  and  communicated  to 
the  affected  groups. 

□  Changes  are  tracked  to  completion. 

Measurements  are  made  and  used  to  determine  the 
functionality  and  quality  of  the  software  products.  (L3-79, 
Ml) 

Measurements  are  made  and  used  to  determine  the  status  of 
the  software  product  engineering  activities.  (L3-80,  M2) 

The  activities  for  software  product  engineering  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L3-80,  VI) 
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Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  activities  for  software  product  engineering  are  reviewed 
with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-80,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  product 
engineering  and  reports  the  results.  (L3-81,  V3) 

[Refer  to  SPE  Process  Reviews  and  Audits  for  additional 
information.] 
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Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  product 
engineering  process. 


V 

Output 

Org.  Outputs 

References 

Architecture  issues  (affecting  the  software 
detailed  design).  (L3-70,  A3,  6) 

Changes  to  allocated  requirements.  (L3- 
67,  A2,  4.1) 

Changes  to  process  descriptions.  (L3-79, 
AlO,  4.3) 

Changes  to  software  activities.  (L3-79, 

AlO,  4.3) 

Changes  to  software  plans.  (L3-79,  AlO, 
4.3) 

Changes  to  the  software  requirements. 
(L3-67,  A2,  4.1) 

Changes  to  software  work  products.  (L3- 
79,  AlO,  4.3) 

Code  unit.  (L3-72,  A4,  3) 

Configuration  management  models.  (L3- 
66,  Al,  3) 

Data  on  defects  identified  in  peer  reviews. 
(L3-78,  A9) 

Data  on  defects  identified  in  testing.  (L3- 
78,  A9) 

Defects  detected  in  SQA  group  reviews 
and/or  audits.  (L3-82,  V3,  8) 

Design  criteria.  (L3-69,  A3,  1) 

Documentation  that  will  be  used  to  operate 
and  maintain  the  software.  (L3-76,  A8) 

Documentation  tracing  the  allocated 
requirements  through  the  software 
requirements,  design,  code,  and  test  cases. 
(L3-78,  AlO,  3) 

Integration  test  cases.  (L3-75,  A6,  2) 

Integration  test  procedures.  (L3-75,  A6,  2) 

Issues  affecting  the  coding.  (L3-71,  A4,  1) 

Issues  affecting  the  software  design.  (L3- 
69,  A3,  2) 
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Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  product 
engineering  process,  continued  from  the  previous  page. 


Output 

Org.  Outputs 

References 

Issues  affecting  the  software  requirements 
analysis.  (L3-66,  A2,  I ) 

Measurements  (to  deteirnine  the 
functionality  and  quality  of  the  software 
products).  (L3-79.  Ml) 

Methods  for  validating  thrt  each  software 
requirement  is  satisfied.  (L3-68,  A2,  7) 

Methods  for  verifying  that  each  software 
requirement  is  satisfied.  (L3-68,  A2,  7) 

Plans  for  integration  testing.  (L3-75,  A6, 

1) 

Problems  detected  in  SQA  group  reviews 
and/or  audits.  (L3-82,  V3,  8) 

Problems  identified  during  testing.  (L3- 
76,  A7,  6) 

Problems  with  the  software  requirements. 
(L3-67,  A2,  4.1) 

Rationale  for  selecting  a  particular 
(software  engineering)  method.  (L3-66, 

Al,  2.1) 

Rationale  for  selecting  a  particular 
(software  engineering)  tool.  (L3-66,  AI, 
2.1) 

Rationale  for  the  selected  alternative.  (L3- 
67,  A2,  3) 

Results  of  SQA  group  reviews  and/or 
audits.  (L3-81,  V3) 

Results  of  the  requirements  analysis.  (L3- 
67,  A2,  3) 

Software  architecture.  (L3-70,  A3,  5) 

Software  code.  (L3-71,  A4) 

Software  design  document.  (L3-71,  A3, 
8.1) 

Software  design.  (L3-69,  A3) 

Software  detailed  design.  (L3-70,  A3,  7) 

Software  plans.  (L3-60,  Cl,  3) 

Software  products.  (L3-60,  Cl,2) 
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Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  product 
engineering  process,  continued  from  the  previous  page. 


r 

Output 

Org.  Outputs 

References 

Software  requirements  document.  (L3-68, 
A2,  8) 

Software  requirements.  (L3-66,  A2) 

Software  work  products.  (L3-78,  AlO,  1) 

Test  cases.  (L3-74,  A5,  6) 

Test  plan.  (L3-74,  A5,  6) 

Test  procedures.  (L3-74,  A5,  6) 

Test  readiness  criteria.  (L3-73,  A5,  4) 

Test  results.  (L3-76,  A7,  7) 

Testing  criteria.  (L3-72,  A5,  I) 
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Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process. 


4 

Output 

State 

References 

Architecture  issues 
(affecting  the 
software  detailed 
design) 

□  are  identified.  (L3-70,  A3,  6) 

□  are  resolved.  (L3-70,  A3,  6) 

Changes  to  allocated 
requirements 

are  made.  (L3-67,  A2,  4.1) 

Changes  to  process 
descriptions 

□  are  analyzed.  (L3-78,  A 10,  4) 

□  are  incorporated  as  appropriate. 
(L3-78,  A 10,  4) 

□  have  their  impact  determined  by 
the  project  before  the  changes 
are  made.  (L3-79,  AlO,  4.1) 

□  are  coordinated.  (L3-79,  AlO, 
4.3) 

□  are  negotiated  with  the  affected 
groups.  (L3-79,  AlO,  4.4) 

□  are  communicated  to  the  affected 
groups.  (L3-79,  AlO,  4.4) 

□  are  tracked  to  completion.  (L3- 
79,  AlO.  4.5) 

Changes  to  software 
activities 

□  are  analyzed.  (L3-78,  AlO,  4) 

□  are  incorporated  as  appropriate. 
(L3-78,  AlO,  4) 

□  have  their  impact  determined  by 
the  project  before  the  changes 
are  made.  (L3-79,  AlO,  4.1) 

□  are  coordinated.  (L3-79,  AlO, 
•^.3) 

□  are  negotiated  with  the  affected 
'roups.  (L3-79,  AlO,  4.4) 

□  are  communicated  to  the  affected 
groups.  (L3-79,  AlO,  4.4) 

□  are  tracked  to  completion.  (L3- 
79,  AlO,  4.5) 

Changes  to  software 
requirements 

are  made  (based  on  problems 
identified  with  the  software 
requirements).  (L3-67,  A2,  4.1) 
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Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


"T 

Output 

State 

References 

Changes  to  software 
plans 

□  are  analyzed.  (L3-78,  A 10,  4) 

□  are  incorporated  as  appropriate. 
(L3-78,  AlO,  4) 

□  have  their  impact  determined  by 
the  project  before  the  changes 
are  made.  (L3-79,  AlO,  4.1) 

□  are  coordinated.  (L3-79,  AlO, 
4.3) 

□  are  negotiated  with  the  aOTected 
groups.  (L3-79,  AlO,  4.4) 

□  are  communicated  to  the  affected 
groups.  (L3-79,  AlO,  4.4) 

□  are  tracked  to  completion.  (L3- 
79,  AlO,  4.5) 

Changes  to  software 
work  products 

□  are  analyzed.  (L3-78,  AlO,  4) 

□  are  incorporated  as  appropriate. 
(L3-78,  AlO,  4) 

□  have  their  impact  determined  by 
the  project  before  the  changes 
are  made.  (L3-79,  AlO,  4.1) 

□  are  coordinated.  {L3-79,  AlO, 
4.3) 

□  are  negotiated  with  the  affected 
groups.  (L3-79,  AlO,  4.4) 

□  are  communicated  to  the  affected 
groups.  (L3-79,  AlO,  4.4) 

□  are  tracked  to  completion.  (L3- 
79,  AlO,  4.5) 
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Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Code  unit 

□  development  sequence  is  based 
on  a  plan  that  accounts  for 
factors  such  as: 

□  criticality, 

□  difficulty, 

□  integration  and  test  issues, 
and 

□  needs  of  the  customer  and 
end  users,  as  appropriate. 
(L3-72,  A4,  3) 

□  undergoes  peer  review.  (L3-72, 
A4,4) 

□  is  unit  tested  before  the  unit  is 
considered  complete.  (L3-72, 
A4,4) 

Configuration 
management  models 

□  are  appropriate  to  the  software 
project.  (L3-66,  Al,  3) 

□  are  selected.  (L3-66,  Al,  3) 

□  are  used.  (L3-66,  Al,  3) 

Data  on  defects 
identified  in  peer 
reviews 

□  are  collected  according  to  the 
project’s  defined  software 
process.  (L3-78,  A9) 

□  are  analyzed  according  to  the 
project’s  defined  software 
process.  (L3-78,  A9) 

Data  on  defects 
identified  in  testing 

□  are  collected  according  to  the 
project’s  defined  software 
process.  (L3-78,  A9) 

□  are  analyzed  according  to  the 
project’s  defined  software 
process.  (L3-78,  A9) 

Design  criteria 

□  are  developed.  (L3-69,  A3,  1) 

□  are  reviewed.  (L3-69,  A3,  1) 
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Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 

exit  criteria,  to  exit  the  software  product  engineering  process,  continued  from  the  previous 

continued  page. 


yl 

Output 

State 

References 

Documentation  (that 
will  be  used  to 
operate  and  maintain 
the  software) 

□  is  developed  according  to  the 
project's  defined  software 
process.  (L3-76,  A8) 

□  is  maintained  according  to  the 
project's  defined  software 
process.  (L3-76,  A8) 

□  is  developed  by  using 
appropriate  methods  and  tools. 
(L3-76,  A8,  1) 

□  (preliminary  versions)  are 
developed.  (L3-77,  A8,  3) 

□  (preliminary  versions)  are  made 
available  early  in  the  software  life 
cycle  for  the  customer,  end 
users,  and  software  maintainers, 
as  appropriate,  to  review  and  to 
provide  feedback.  (L3-77,  A8, 

3) 

□  (final  versions)  are  verified 
against  the  software  baselined  for 
software  acceptance  testing.  (L3- 
77,  A8,  4) 

□  undergoes  peer  review.  (L3-77, 
A8,  5) 

□  is  managed  and  controlled.  (L3- 
77,  A8,  6) 

□  (final  version)  is  reviewed  by  the 
customer,  end  users,  and 
software  maintainers,  as 
appropriate.  (L3-77,  A8,  7) 

□  (final  version^  is  approved  by  the 
customer,  end  users,  and 
software  maintainers,  as 
appropriate.  (L3-77,  A8,  7) 

□  is  verified  against  the  software 
baseline  and  any  applicable 
allocated  requirements  before  the 
software  product  is  released  to 
the  customer  or  end  users.  (L.’ 
82,  V3,  10) 
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Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Documentation 
(tracing  the  allocated 
requirements  through 
the  software 
requirements,  design, 
code,  and  test  cases) 

is  managed  and  controlled.  (L3-78, 
AlO,  3) 

Integration  test  cases 

are  reviewed  with  the  individuals 
responsible  for  the  software 
requirements,  software  design,  and 
system  and  acceptance  testing.  (L3- 
75,  A6,  2) 

Issues  affecting  the 
coding 

□  are  identified.  (L3-71,  A4,  1) 

□  are  resolved.  (L3-71,  A4,  1) 

Issues  affecting  the 
software  design 

□  are  identified.  (L3-69,  A3,  2) 

□  are  resolved.  (L3-69,  A3,  2) 

Issues  affecting  the 
software 

requirements  analysis 

□  are  identified.  (L3-66,  A2,  1) 

□  are  resolved.  (L3-66,  A2,  1) 

Measurements  (to 
determine  the 
functionality  and 
quality  of  the 
software  products) 

□  are  made.  (L3-79,  Ml) 

□  are  used.  (L3-79,  Mi, 

Measurements  (to 
determine  the  status 
of  the  software 
product  engineering 
activities) 

□  are  made.  (L3-80,  M2) 

□  are  used.  (L3-80,  M2) 

Methods  for 
validating  that  each 
software  requirement 
is  satisfied 

□  are  identified.  (L3-68,  A2,  7) 

□  are  document  ;d.  (L3-68,  A2,  7) 

Methods  for 
verifying  that  each 
software  requirement 
is  satisfied 

□  are  identified.  (L3-68,  A2,  7) 

□  are  documented.  (L3-68,  A2,  7) 
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Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Plans  for  integration 
testing 

□  are  documented.  (L3-75,  A6,  1) 

□  are  based  on  the  software 
development  plan.  (L3-75,  A6. 

1) 

Problems  identified 
during  testing 

□  are  documented.  (L3-76,  A7,  6) 

□  are  tracked  to  closure.  (L3-76, 
A7,6) 

Problems  with  the 

software 

requirements 

□  are  identified.  (L3-67,  A2,  4.1) 

□  are  reviewed  with  the  group 
responsible  for  the  system 
requirements.  (L3-67,  A2,  4.1) 

Rationale  for 
selecting  a  particular 
method 

is  documented.  (L3-66,  Al,  2.1) 

Rationale  for 
selecting  a  particular 
tool 

is  documented.  (L3-66,  Al,  2.1) 

Rationale  for  the 
selected  alternative 

is  documented.  (L3-67,  A2,  3) 

Results  of  SQA 
group  reviews  and/or 
audits 

are  reported.  (L3-81,  V3) 

Results  of  the 
requirements  analysis 

are  documented.  (L3-67,  A2,  3) 

Software  architecture 

□  is  developed  early,  within  the 
constraints  of  the  software  life 
cycle  and  technology  being 
used.  (L3-70,  A3,  5) 

□  is  reviewed  to  ensure  that 
architecture  issues  affecting  the 
software  detailed  design  are 
identified  and  resolved.  (L3-70, 
A3,  6) 

□  is  documented.  (L3-70,  A3,  8) 
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Output'based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
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continued  page. 


T 

Output 

State 

References 

Software  code 

□  is,  (according  to  the  project’s 
defined  software  process, )  (L3- 
71,  A4) 

□  developed, 

□  maintained, 

□  documented,  and 

□  verified. 

□  implements  the  software 
requirements  and  software 
design.  (L3-71,  A4) 

□  is  placed  under  configuration 
management.  (L3-72,  A4,  5) 

□  is  appropriately  changed 
whenever  the  software 
requirements  or  software  design 
changes.  (L3-72,  A4,  6) 

Software  design 
document 

□  undergoes  peer  review  before  the 
design  is  considered  complete. 
(L3-71,  A3,  9) 

□  is  placed  under  configuration 
management.  (L3-71,  A3,  10) 

□  is  appropriately  changed 
whenever  the  software 
requirements  change.  (L3-71, 

A3,  11) 

Software  design 

□  is,  according  to  the  project’s 
defined  software  process,  (L3- 
69,  A3) 

□  developed, 

□  maintained, 

□  documented,  and 

□  verified. 

□  accommodates  the  software 
requirements.  (L3-69,  A3) 

□  forms  the  framework  for  coding. 
(L3-69,  A3) 

□  is  documented.  {L3-70,  A3,  8) 
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Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Software  detailed 
design 

□  is  developed  based  on  the 
software  architecture.  (L3-70, 

A3,  7) 

□  is  documented.  (L3-70,  A3,  8) 

Software  plans 

are  traceable  to  the  system 
requirements  allocated  to  software. 
(L3-60,  Cl,  3) 

Software  products 

□  are  b"ilt  using  appropriate 
methods  and  tools.  (L3-60,  Cl, 

2) 

□  are  maintained  using  appropriate 
methods  and  tools.  (L3-60,  Cl, 

2) 

□  are  traceable  to  the  system 
requirements  allocated  to 
software.  (L3-60,  Cl,3) 

□  comply  with  the  standards  and 
requirements  specified  for  them. 
(L3-81,  V3,  3) 

Software 

requirements 

document 

□  undergoes  peer  review  before  it 
is  considered  complete.  (L3-68, 
A2,  8) 

□  is  reviewed.  (L3-68,  A2,  9) 

□  is  approved.  (L3-68,  A2,  9) 

□  is  reviewed  with  the  customer 
and  end  users,  as  appropriate. 
(L3-68,  A2,  10) 

□  is  placed  under  configuration 
management.  (L3-69,  A2,  1 1) 
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( >utput-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Software 

requirements 

□  are:  (L3-66,  A2) 

□  developed, 

□  maintained, 

□  documented,  and 

□  verified  by  systematically 
analyzing  the  allocated 
requirements  according  to 
the  project’s  defined  software 
process. 

□  are  identified  using  effective 
methods  for  requirements 
analysis.  (L3-67,  A2,  2) 

□  are  derived  using  effective 
methods  for  requirements 
analysis.  (L3-67,  A2,  2) 

□  are  analyzed  to  ensure  they  are; 
(L3-67,  A2,  4) 

□  feasible  and  appropriate  to 
implement  in  software, 

□  clearly  stated, 

□  consistent  with  each  other, 

□  testable,  and 

□  complete  (when  considered 
as  a  set). 

□  are  documented.  (L3-67,  A2,  5) 

□  (each)  is  analyzed  by  the  group 
responsible  for  system  and 
acceptance  testing  to  verify  it 
can  be  tested.  (L3-67,  A2,  6) 

□  are  appropriately  changed 
whenever  the  allocated 
requirements  change.  (L3-69, 
A2,  12) 

Software  work 
products 

are  documented,  and  the 
documentation  is  readily  available. 
(L3-78,  A 10,  1) 

Continued  on  next  page 


L3-Process-134 


CMU/SEI-94-HB-1 


SPE  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Test  cases 

□  undergo  peer  review  before  they 
are  considered  ready  for  use. 
(L3-74,  A5,  6) 

□  are  managed  and  controlled. 
{L3-74,  A5,  7) 

□  are  appropriately  changed 
whenever  the  allocated 
requirements,  software 
requirements,  software  design,  or 
code  being  tc  'ed  changes.  (L3- 
74,  A5,  8) 

□  are  planned  and  prepared  by  a 
test  group  that  is  independent  of 
the  software  developers.  (L3-76, 
A7,  3) 

□  are  documented.  (L3-76,  A7,  4) 

□  are  reviewed  with  the  customer 
and  end  users,  as  appropriate, 
before  the  testing  begins.  (L3- 
76,  A7,  4) 

□  are  approved  by  the  customer 
and  end  users,  as  appropriate, 
before  the  testing  begins.  (L3- 
76,  A7,  4) 
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Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


"T 

Output 

State 

References 

Test  plan 

□  undergoes  peer  review  before  it 
is  considered  ready  for  use.  (L3- 
74.  A5,  6) 

□  is  managed  and  controlled.  (L3- 
74,  A5,  7) 

□  is  appropriately  changed 
whenever  the  allocated 
requirements,  software 
requirements,  software  design,  or 
code  being  tested  changes.  (L3- 

74,  A5,  8) 

□  is  reviewed  with  the  customer 
and  end  users,  as  appropriate. 
(L3-75.  A7,  2) 

□  is  approved  by  the  customer  and 
end  users,  as  appropriate.  (L3' 

75,  A7,  2) 

Test  procedures 

□  undergo  peer  review  before  they 
are  considered  ready  for  use. 
(L3-74,  A5,  6) 

□  are  managed  and  controlled. 
(L3-74,  A5,  7) 

□  are  appropriately  changed 
whenever  the  allocated 
requirements,  software 
requirements,  software  design,  or 
code  being  tested  changes.  (L3- 
74,  A5,  8) 

□  are  planned  and  prepared  by  a 
test  group  that  is  independent  of 
the  software  developers.  (L3-76, 
A7,  3) 

Test  readiness  criteria 

□  are  established.  (L3-73,  A5,  4) 

□  are  used.  (L3-73,  A5,  4) 
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Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Test  results 

□  are  documented.  (L3-76,  A7,  7) 

□  are  used  as  tne  basis  for 
determining  whether  the  software 
satisfies  its  requirements.  (L3- 
76,  A7,  7) 

□  are  managed  and  controlled. 
(L3-76,  A7,  8) 

Testing  criteria 

□  are  developed.  (L3-72,  A5,  1) 

□  are  reviewed  with  the  customer 
and  the  end  users,  as  appropriate. 
(L3-72,  A5,  1) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  product  engineering  process. 


V 

Condition 

References 

The  software  engineering  tasks  are  performed  in  accordance 
with  the  project's  defined  software  process.  (L3-60,  Cl,  1) 

Appropriate  software  engineering  methods  and  tools  are 
integrated  into  the  project's  defined  software  process.  (L3- 
65,  Al) 

The  software  engineering  tasks  are  integrated  according  to 
the  project's  defined  software  process.  (L3-65,  Al,  1) 

Methods  and  tools  appropriate  for  use  on  the  software 
project  are  selected.  (L3-65,  Al,  2) 

Effective  methods  for  requirements  analysis  are  used  to 
identify  and  derive  the  software  requirements.  (L3-67,  A2, 

2) 

Problems  with  the  software  requirements  are  identified  and 
reviewed  with  the  group  responsible  for  the  system 
requirements;  appropriate  changes  are  made  to  the  allocated 
requirements  and  to  the  software  requirements.  (L3-67,  A2, 
4.1) 

The  individuals  involved  in  the  software  design  review  the 
software  requirements  to  ensure  that  issues  affecting  the 
software  design  are  identified  and  resolved.  (L3-69,  A3,  2) 

Application  standards  are  used  where  appropriate.  (L3-70, 
A3,  3) 
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General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


V 

Condition 

References 

Effective  methods  are  used  to  design  the  software.  (L3-70, 
A3,  4) 

The  individuals  involved  in  coding  review  the  software 
requirements  and  software  design  to  ensure  that  issues 
affecting  the  coding  ate  identified  and  resolved.  (L3-7I. 

A4,  1) 

Effective  programming  methods  are  used  to  code  the 
software.  (L3-71,  A4,  2) 

Software  testing  is  performed  according  to  the  project's 
defined  software  process.  (L3-72,  A5) 

Effective  methods  are  used  to  test  the  software.  (L3-72,  A5, 
2) 

The  adequacy  of  testing  is  determined  based  on:  (L3-72, 

A5,  3) 

□  the  level  of  testing  performed, 

□  the  test  strategy  selected,  and 

□  the  test  coverage  to  be  achieved. 

Regression  testing  is  performed,  as  appropriate,  at  each  test 
level  whenever  the  software  being  lested  or  its  environment 
changes.  (L3-74,  A5,  5) 

Integration  testing  of  the  software  is  planned  and  performed 
according  to  the  project's  defined  software  process.  (L3-74, 
A6) 

Integration  testing  of  the  software  is  performed  against  the 
designated  version  of  the  software  requirements  document 
and  the  software  design  document.  (L3-75,  A6,  3) 

System  and  acceptance  testing  of  the  software  are  planned 
and  performed  to  demonstrate  that  the  software  satisfies  its 
requirements.  (L3-75,  A7) 

Resources  for  testing  the  software  are  assigned  early  enough 
to  provide  for  adequate  test  preparation.  (L3-75,  A7,  1) 

Testing  of  the  .software  is  performed  against  baselined 
software  and  the  baselined  documentation  of  the  allocated 
requirements  and  the  software  requirements.  (L3-76,  A7,  5) 
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General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  product  engineering  process,  continued  from  the  previous 
page. 


V 

Condition 

References 

Documentation  specialists  actively  participate  in  planning, 
developing,  and  maintaining  documentation.  (L3-77,  A8,  2) 

Consistency  is  maintained  across  software  work  products, 
including  the  software  plans,  process  descriptions,  allocated 
requirements,  software  requirements,  software  design,  code, 
test  plans,  and  test  procedures.  (L3-78,  A 10) 

□  The  software  requirements,  design,  code,  and  test  cases 
are  traced  to  the  source  from  which  they  were  derived 
and  to  the  products  of  the  subsequent  software 
engineering  activities.  (L3-78,  AlO,  2) 

The  activities  for  software  product  engineering  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L3-80,  VI) 

The  activities  for  software  product  engineering  are  reviewed 
with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-80,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  product 
engineering  and  reports  the  results.  (L3-81,  V3) 

Readiness  and  completion  criteria  for  each  software 
engineering  task  are  satisfied.  (L3-81,  V3,  2) 

Required  testing  is  performed.  (L3-81,  V3,  4) 

System  and  acceptance  testing  of  the  software  are  performed 
according  to  documented  plans  and  procedures.  (L3-81, 

V3,  5) 

Tests  satisfy  their  acceptance  criteria,  as  documented  in  the 
software  test  plan.  (L3-81,V3,  6) 

Tests  are  satisfactorily  completed  and  recorded.  (L3-81,  V3, 
7) 

Problems  and  defects  detected  are  documented,  tracked,  and 
addressed.  (L3-82,  V3,  8) 

Tracing  of  the  allocated  requirements  through  the  software 
requirements,  design,  code,  and  test  cases  is  performed.  (L3- 
82,  V3,  9) 

The  documentation  used  to  operate  and  maintain  the 
software  is  verified  against  the  software  baseline  and  any 
applicable  allocated  requirements  before  the  software 
product  is  released  to  the  customer  or  end  users.  (L3-82. 

V3,  10) 
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Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  product 
engineering  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  individuals  involved  in  developing 
the  software  requirements  review  the 
allocated  requirements  to  ensure  that  issues 
affecting  the  software  requirements 
analysis  are  identified  and  resolved.  (L3- 
66,  A2,  1) 

Individuals 
involved  in 
developing  the 
software 
requirements 

Problems  with  the  software  requirements 
are  identified  and  reviewed  with  the  group 
responsible  for  the  system  requirements; 
appropriate  changes  are  made  to  the 
allocated  requirements  and  to  the  software 
requirements.  (L3-67,  A2,  4.1) 

Group 

responsible  for 
the  system 
requirements 

The  software  requirements  document 
undergoes  peer  review  before  it  is 
considered  complete.  (L3-68,  A2,  8) 

Not  speciHed  in 
theCMM 

The  software  requirements  document  is 
reviewed  and  approved.  (L3-68,  A2,  9) 

Not  specified  in 
theCMM 

The  software  requirements  document  is 
reviewed  with  the  customer  and  end  users, 
as  appropriate.  (L3-68,  A2,  10) 

Customer 

End  Users 

Design  criteria  are  developed  and  reviewed. 
(L3-69,  A3,  1) 

Not  specified  in 
theCMM 

The  individuals  involved  in  the  software 
design  review  the  software  requirements  to 
ensure  that  issues  affecting  the  software 
design  are  identified  and  resolved.  (L3-69, 
A3,  2) 

Individuals 
involved  in  the 
software 
design 

The  software  architecture  is  reviewed  to 
ensure  that  architecture  issues  affecting  the 
software  detailed  design  are  identified  and 
resolved.  (L3-70,  A3,  6) 

Not  specified  in 
the  CMM 

The  software  design  document  undergoes 
peer  review  before  the  design  is  considered 
complete.  (L3-71,  A3,  9) 

Not  specified  in 
the  CMM 

The  individuals  involved  in  coding  review 
the  software  requirements  and  software 
design  to  ensure  that  issues  affecting  the 
coding  are  identified  and  resolved.  (L3- 
71,  A4,  1) 

Individuals 
involved  in 
coding 
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Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

Each  code  unit  undergoes  peer  review  and 
is  unit  tested  before  the  unit  is  considered 
complete.  (L3-72,  A4,  4) 

Not  speciHed  in 
the  CMM 

Testing  criteria  are  developed  and  reviewed 
with  the  customer  and  the  end  users,  as 
appropriate.  (L3-72,  A5,  1) 

Customer 

End  users 

Tlie  test  plan,  test  procedures,  and  test  cases 
undergo  peer  review  before  they  are 
considered  ready  for  use.  (L3-74,  A5,  6) 

Not  specified  in 
the  CMM 

The  integration  test  cases  and  test 
procedures  are  reviewed  with  the 
individuals  responsible  for  the  software 
requirements,  software  design,  and  system 
and  acceptance  testing.  (L3-75,  A6,  2) 

Individuals 
responsible  for 
the  software 
requirements, 
software 
design,  and 
system  and 
acceptance 
testing 

System  and  acceptance  testing  are 
documented  in  a  test  plan,  which  is 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as  appropriate. 
(L3-75,  A7,  2) 

Customer 

End  users 

The  test  cases  are  documented  and  are 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as  appropriate, 
before  the  testing  begins.  (L3-76,  A7,  4) 

Customer 

End  users 

Preliminary  versions  of  the  documentation 
(that  will  be  used  to  operate  and  maintain 
the  software)  are  developed  and  made 
available  early  in  the  software  life  cycle  for 
the  customer,  end  users,  and  software 
maintai  lers,  as  appropriate,  to  review  and 
provide  feedback.  (L3-77,  A8,  3) 

Customer 

End  users 

Software 

maintainers 

The  documentation  (that  will  be  used  to 
operate  and  maintain  the  software) 
undergoes  peer  review.  (L3-77,  A8,  5) 

Not  specified  in 
the  CMM 
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Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  final  documentation  (that  will  be  used 
to  operate  and  maintain  the  software)  is 
reviewed  and  approved  by  the  customer, 
end  users,  and  software  maintainers,  as 
appropriate.  (L3-77,  A8,  7) 

Customer 

End  users 

Software 

maintainers 

The  activities  for  software  product 
engineering  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L3-80, 
VI) 

Senior 

management 

The  activities  for  software  product 
engineering  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L3-80,  V2) 

Project 

manager 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  product  engineering 
and  reports  the  results.  (L3-81,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify  that: 

□  The  software  requirements  are  reviewed 
to  ensure  that  they  are: 

□  complete, 

□  correct, 

□  consistent, 

□  feasible,  and 

□  testable. 

□  Readiness  and  completion  criteria  for 
each  software  engineering  task  are 
satisfied. 

□  Software  products  comply  with  the 
standards  and  requirements  specified 
for  them. 

□  Required  testing  is  performed. 

□  System  and  acceptance  testing  of  the 
software  are  performed  according  to 
documented  plans  and  procedures. 

SQA  group 

This  review  continued  on  next  page 
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audits, 

continued 


The  labie  below  lists  the  required  reviews  and  audits  for  the  software  product 
engineering  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

This  review  continued  from  previous  page 

□  Tests  satisfy  their  acceptance  criteria,  as 
documented  in  the  software  test  plan. 

□  Tests  are  satisfactorily  completed  and 
recorded. 

□  Problems  and  defects  detected  are 
documented,  tracked,  and  addressed. 

□  Tracing  of  the  allocated  requirements 
through  the  software  requirements, 
design,  code,  and  test  cases  is 
performed. 

□  The  documentation  used  to  operate 
and  maintain  the  software  is  verified 
against  the  software  baseline  and  any 
applicable  allocated  requirements 
before  the  software  product  is  released 
to  the  customer  or  end  users.. 

SQA  group 
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Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  software  product  engineering  process. 


Work  Products  Managed  and  Controlled 

References 

Tools  used  to  develop  and  maintain  the  software  products.* 
(L3-66,  Al,  4) 

Software  requirements  document.'  (L3-69,  A2,  1 1) 

Software  design  document.'  (L3-71,  A3,  10) 

Code.'  (L3-72,  A4,  5) 

Test  plans,  test  procedures,  and  test  cases.  (L3-74,  A5,  7) 

Test  results.  (L3-76,  A7,  8) 

Documentation  (that  will  be  used  to  operate  and  maintain 
the  software).  (L3-77,  A8,  6) 

Documentation  tracing  the  allocated  requirements  through 
the  software  requirements,  design,  code,  and  test  cases.  (L3- 
78,  AlO,  3) 

'Indicates  that  the  CMM  recommends  that  this  item  be  placed  under  configuration 
management 
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SPE  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  software  product 
engineering  process. 


V 

Measurements 

References 

Data  on  defects  identified  in  peer  reviews.  (L3-78,  A9) 

Data  on  defects  identified  in  testing.  (L3-78,  A9) 

Measurements  to  determine  the  functionality  and  quality  of 

the  software  products.  (L3-79,  Ml) 

Examples  of  measurements  include: 

□  Numbers,  types,  and  severity  of  defects  identified  in  the 
software  products  tracked  cumulatively  and  by  stage. 

□  Allocated  requirements  summarized  by  category  (e.g., 
security,  system  configuration,  performance,  and 
reliability),  and  traced  to  the  software  requirements  and 
system  test  cases. 

Measurements  to  determine  the  status  of  the  software 

product  engineering  activities.  (L3-80,  M2) 

Examples  of  measurements  include: 

□  Status  of  each  allocated  requirement  throughout  ;he  life 
of  the  project. 

□  Problem  reports  by  severity  and  length  of  time  they  are 
open. 

□  Change  activity  for  the  allocated  requirements. 

□  Effort  to  analyze  proposed  changes  for  each  pioposed 
change  and  cumulative  totals. 

□  Number  of  changes  incorporated  into  the  software 
baseline  by  category  (e.g.,  interface,  security,  system 
configuration,  performance,  and  usability). 

□  Size  and  cost  to  implement  and  test  incorporated 
changes,  including  initial  estimate  and  actual  size  and 
cost. 
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SPE  Process  -  Documented  Procedures 


Documented 

procedures 


There  are  no  activities  that  are  recommended  to  be  performed  according  to  a 
documented  procedure  in  the  software  product  engineering  process. 
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SPE  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  product 
engineering  process. 


T 

Training 

References 

Members  of  the  software  engineering  technical  staff  receive 
required  training  to  perform  their  technical  assignments. 
(L3-63,  Ab2) 

Members  of  the  software  engineering  technical  staff  receive 
orientation  in  related  software  engineering  disciplines.  (L3- 
64,  Ab3) 

■  _..i 

The  project  manager  and  all  software  managers  receive 
orientation  in  the  technical  aspects  of  the  software  project. 
(L3-64,  Ab4) 
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Tools 


The  table  below  lists  the  tools  recommended  for  the  software  product  engineering 
process. 


'T 

Tools 

References 

Tools  to  build  and  maintain  the  software  products.  (L3-60, 
Cl.  2) 

Tools  to  support  the  software  engineering  tasks.  (L3-61, 

Abl,  2) 

Examples  of  support  tools  include: 

□  workstations, 

□  database  management  systems, 

□  on-line  help  aids, 

□  graphics  tools. 

□  interactive  documentation  tools,  and 

□  word  processing  systems. 

Software  engineering  tools.  (L3-65,  Al) 

Tools  to  develop  the  documentation.  (L3-76,  A8,  I) 
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Intergroup  Coordination  (1C)  Process 
1C  Process  -  Overview 


IC  process 
purpose 


IC  process 
description 


The  purpose  of  Intergroup  Coordination  is  to  establish  a  means  for  the  software 
engineering  group  to  participate  actively  with  the  other  engineering  groups  so  the 
project  is  better  able  to  satisfy  the  customer's  needs  effectively  and  efficiently. 
(L3-83) 


Intergroup  Coordination  involves  the  software  engineering  group's  participation 
with  other  project  engineering  groups  to  address  system-level  requirements, 
objectives,  and  issues.  Representatives  of  the  project's  engineering  groups 
participate  in  establishing  the  system-level  requirements,  objectives,  and  plans  by 
working  with  the  customer  and  end  users,  as  appropriate.  These  requirements, 
objectives,  and  plans  become  the  basis  for  all  engineering  activities. 

The  technical  working  interfaces  and  interactions  between  groups  are  planned  and 
managed  to  ensure  the  quality  and  integrity  of  the  entire  system.  Technical 
reviews  and  interchanges  are  regularly  conducted  with  representatives  of  the 
project's  engineering  groups  to  ensure  that  all  engineering  groups  are  aware  of  the 
status  and  plans  of  all  the  groups,  and  that  system  and  intergroup  issues  receive 
appropriate  attention. 

The  software-specific  practices  related  to  these  engineering  tasks  are  described  in 
the  Requirements  Management  and  Software  Product  Engineering  key  process 
areas.  (L3-83) 


Continued  on  next  page 
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1C  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-151 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-158 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-159 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-160 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-162 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process-164 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L3-Process-172 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled.. 

L3-Process-174 

Measurements 

Description  of  process  measurements. 

L3-Process-175 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-176 

Training 

List  of  training. 

L3-Process-l77 

Tools 

List  of  tools. 

L3-Process-178 
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1C  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
intergroup  coordination  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

The  system  requirements  and  project-level 
objectives  for  the  project  are  defined  and 
reviewed  by  all  affected  groups.  (L3-84, 
Cl.l) 

Customers 

The  software  engineering  group  and  the 
other  engineering  groups  participate  with 
the  customer  and  end  users,  as  appropriate, 
to  establish  the  system  requirements.  (L3- 
86,  Al) 

End  users 

The  software  engineering  group  and  the 
other  engineering  groups  participate  with 
the  customer  and  end  users,  as  appropriate, 
to  establish  the  system  requirements.  (L3- 
86,  AI) 

Continued  on  next  page 
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1C  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
intergroup  coordination  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Engineering 

groups 

□  The  engineering  groups  coordinate 
their  plans  and  activities.  (L3-84,  Cl, 

2) 

□  The  members  of  the  engineering 
groups  receive  orientation  in  working 
as  a  team.  (L3-86.  Ab5) 

□  The  software  engineering  group  and 
the  other  engineering  groups 
participate  with  the  customer  and  end 
users,  as  appropriate,  to  establish  the 
system  requirements.  (L3-86,  Al) 

Specifically,  these  groups: 

□  Define  the  critical  characteristics  of 
the  customer's  and  end  users’ 
requirements,  as  appropriate. 

□  Negotiate  critical  dependencies. 

□  Document  the  acceptance  criteria 
for  each  product  delivered  to  the 
customer  or  end  user,  as 
appropriate. 

□  The  plan  used  to  communicate 
intergroup  commitments  and  track  the 
work  performed  is  reviewed  and  agreed 
to  by  all  engineering  groups  and  the 
project  manager.  (L3-89,  A3,  6) 

□  Critical  dependencies  are  negotiated 
between  the  software  engineering 
group  and  other  engineering  groups  in 
the  project  and  organization.  (L3-89, 
A4,  2) 

Group 

responsible  for 
providing  the 
critical 
dependency 
item 

The  agreement  for  each  critical 
dependency  is  documented,  reviewed,  and 
approved  by  both  the  receiving  group  and 
the  group  responsible  for  provid^ing  the 
critical  dependency  item.  (L3-89,  A4,  4) 

Continued  on  next  page 
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1C  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
intergroup  coordination  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Manager 

□  Managers  are  responsible  for 
establishing  and  maintaining  an 
environment  to  facilitate  interaction, 
coordination,  support,  and  teamwork 
between  the  project's  engineering 
groups,  between  the  project  and  the 
customer  or  end  users,  as  appropriate, 
and  throughout  the  organization.  (L3- 
85,  Cl,  3) 

□  All  managers  in  the  organization 
receive  required  training  in  teamwork. 
(L3  85,  Ab3) 

□  Actual  and  potential  problems  are 
reported  to  the  appropriate  managers. 
(L3-89,  A4,  5.3) 

Project 

manager 

□  The  documented  plan  that  is  used  to 
communicate  intergroup  commitments 
and  to  coordinate  and  track  the  work 
performed  is  reviewed  and  agreed  to  by 
all  engineering  groups  and  the  project 
manager.  (L3-89,  A3,  6) 

□  The  activities  for  intergroup 
coordination  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  basis.  (L3-92,  V2) 

Receiving 
group  of  a 
critical 
dependency 
item 

The  agreement  for  each  critical 
dependency  is  documented,  reviewed,  and 
approved  by  both  the  receiving  group  and 
the  group  responsible  for  providing  the 
critical  dependency  item.  (L3-89,  A4,  4) 

Continued  on  next  page 
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1C  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
intergroup  coordination  process,  continued  from  the  previous  page. 


< 

Role 

Activities  Participated  in... 

Reference 

Representa¬ 
tive’s  of  the 
project’s 
software 
engineering 
group 

□  Representatives  of  the  project's 
software  engineering  group  work  with 
representatives  of  the  other  engineering 
groups  to  monitor  and  coordinate 
technical  activities  and  resolve  technical 
issues.  (L3-87,  A2) 

□  The  representatives  of  these  groups 
monitor  and  coordinate  technical 
activities  by:  (L3-87,  A2,  1 ) 

□  coordinating  the  specification  and 
providing  the  technical  review  and 
approval  of  the  system 
requirements  and  system  design; 

□  providing  the  project-level 
technical  review  and  analysis 
needed  to  manage  and  control 
changes  to  the  system  requirements 
and  project-level  objectives 
throughout  the  project’s  life  cycle; 

□  tracking  and  reviewing  the  design 
and  development  activities  for 
hardware,  software,  and  other 
system  components;  and 

□  assessing,  developing 
recommendations  for,  and  tracking 
technical  risks  that  involve  more 
than  one  engineering  group. 

□  The  representatives  of  the  groups 
handle  technical  issues  by:  (L3-88,  A2, 
2) 

□  resolving  project-level  conflicts  and 
clarifying  system  requirements  and 
design  issues; 

□  developing  joint  recommendations 
to  resolve  problems;  and 

□  addressing  process  issues  that  span 
the  engineering  groups  of  the 
project. 

Continued  on  next  page 
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1C  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
intergroup  coordination  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Representa¬ 
tives  of  the 
other 

engineering 

groups 

□  Representatives  of  the  project's  software 
engineering  group  work  with 
representatives  of  the  other 
engineering  groups  to  monitor  and 
coordinate  technical  activities  and 
resolve  technical  issues.  (L3-87,  A2) 

□  The  representatives  of  these  groups 
monitor  and  coordinate  technical 
activities  by:  (L3-87,  A2,  1) 

□  coordinating  the  specification  and 
providing  the  technical  review  and 
approval  of  the  system 
requirements  and  system  design; 

□  providing  the  project-level 
technical  review  and  analysis 
needed  to  manage  and  control 
changes  to  the  system  requirements 
and  project-level  objectives 
throughout  the  project's  life  cycle; 

□  tracking  and  reviewing  the  design 
and  development  activities  for 
hardware,  software,  and  other 
system  components;  and 

□  assessing,  developing 
recommendations  for,  and  tracking 
technical  risks  that  involve  more 
than  one  engineering  group. 

□  The  representatives  of  the  groups 
handle  technical  issues  by:  (L3-88,  A2, 
2) 

□  resolving  project-level  conflicts  and 
clarifying  system  requirements  and 
design  issues; 

□  developing  joint  recommendations 
to  resolve  problems;  and 

□  addressing  process  issues  that  span 
the  engineering  groups  of  the 
project. 
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1C  Process  -  Roles,  Continued 


Rotes, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
intergroup  coordination  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Representa¬ 
tives  of  the 
project 
engineering 
groups 

□  Intergroup  issues  not  resolvable  by  the 
individual  representatives  of  the 
project  engineering  groups  are 
handled  according  to  a  documented 
procedure.  (L3-90,  A6) 

□  Representatives  of  the  project 
engineering  groups  conduct  periodic 
technical  reviews  and  interchanges. 
(L3-90.  A7) 

Representa¬ 
tives  of  the 
receiving 
group  of  a 
critical 
dependency 
item 

Work  products  produced  as  input  to  other 
engineering  groups  are  reviewed  by 
representatives  of  the  receiving  groups  to 
ensure  that  the  work  products  meet  their 
needs.  (L3-90,  A5) 

Senior 

management 

The  activities  for  intergroup  coordination 
are  reviewed  with  senior  management  on  a 
periodic  basis.  (L3-91,  VI) 

Software 

engineering 

group 

□  The  software  engineering  group  and 
the  other  engineering  groups 
participate  with  the  customer  and  end 
users,  as  appropriate,  to  establish  the 
system  requirements.  (L3-86,  Al) 

Specifically,  these  groups: 

□  define  the  critical  characteristics  of 
the  customer's  and  end  users' 
requirements,  as  appropriate; 

□  negotiate  critical  dependencies;  and 

□  document  the  acceptance  criteria 
for  each  product  delivered  to  the 
customer  or  end  user,  as 
appropriate. 

□  Critical  dependencies  are  negotiated 
between  the  software  engineering 
group  and  other  engineering  groups  in 
the  project  and  organization.  (L3-89, 
A4,  2) 

Continued  on  next  page 
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1C  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
intergroup  coordination  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 

quality 

assurance 

group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  intergroup  coordination  and 
reports  the  results.  (L3-92,  V3) 

Task  leaders 

All  task  leaders  in  each  engineering  group 
receive  orientation  in  the  processes, 
methods,  and  standards  used  by  the  other 
engineering  groups.  (L3-86,  Ab4) 

CMU/SEI-94-HB-1 


L3-Process-157 


1C  Process  -  Entry  Criteria 


Input-based  The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
entry  criteria  before  entering  the  intergroup  coordination  process. 


V 

Input 

State 

References 

_ 1 

Plan  used  to 
communicate 
intergroup 
commitments  and  to 
coordinate  and  track 
the  work  performed 

is  documented.  (L3-88,  A.3) 

General  entry  The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
criteria  before  entering  the  intergroup  coordination  process. 


Condition 

References 

The  project  follows  a  written  organizational  policy  for 
establishing  interdisciplinary  engineering  teams.  (L3-84, 

Cl) 

Adequate  resources  and  funding  are  provided  for 
coordinating  the  software  engineering  activities  with  other 
engineering  groups.  (L3-85,  Abl) 

The  support  tools  used  by  the  different  engineering  groups 
are  compatible  to  enable  effective  communication  and 
coordination.  (L3-85,  Ab2) 

All  managers  in  the  organization  receive  required  training 
in  teamwork.  (L3-85,  Ab3) 

All  task  leaders  in  each  engineering  group  receive 
orientation  in  the  processes,  methods,  and  standards  used  by 
the  other  engineering  groups.,  (L3-86,  Ab4) 

The  members  of  the  engineering  groups  receive  orientation 
in  working  as  a  team.  (L3-86,  Ab5) 

L3-Process-158 


CI\/IU/SEl-94-HB-1 


1C  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  intergroup  coordination 
process. 


Input 

Org.  Input 

References 

Actual  completion  (of  critical 
dependencies).  (L3-89,  A4,  5.1) 

Changes  to  intergroup  commitments.  (L3- 
88,  A3,  4) 

Changes  to  the  plan  (used  to  communicate 
intergroup  commitments  and  to  coordinate 
and  track  the  work  performed).  (L3-88, 

A3,  5) 

Changes  to  the  project-level  objectives. 
(L3-87,  A2,  1.2) 

Changes  to  the  system  requirements.  (L3- 
87,  A2,  1.2) 

Commitments.  (L3-90,  A7,  4) 

Customer’s  requirements.  (L3-87,  Al,  1) 

End  users’  requirements.  (L3-87,  Al,  1) 

Intergroup  commitments.  (L3-88,  A3) 

Plan  (used  to  communicate  intergroup 
commitments  and  to  coordinate  and  track 
the  work  performed).  (L3-88,  A3) 

Project  schedule.  (L3-89,  A4,  3) 

Projected  completion  (of  critical 
dependencies).  (L3-89,  A4,  5.1) 

Software  schedule.  (L3-89,  A4,  3) 

Status  (of  critical  dependencies).  (L3-89, 
A4,  5.1) 

System  requirements.  (L3-90,  A7,  3) 

Technical  issues.  (L3-90,  A7,  5) 

Technical  requirements.  (L3-90,  A7,  3) 

Technical  risks.  (L3-88,  A2,  1.4) 

1 
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1C  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  intergroup  coordination 
process. 


V 

Activities 

References 

The  software  engineering  group  and  the  other  engineering 
groups  participate  with  the  customer  and  end  users,  as 
appropriate,  to  establish  the  system  requirements.  (L3-86, 
Al) 

Specifically,  these  groups; 

□  Define  the  critical  characteristics  of  the  customer's  and 
end  users'  requirements,  as  appropriate. 

□  Negotiate  critical  dependencies. 

□  Document  the  acceptance  criteria  for  each  product 
delivered  to  the  customer  or  end  user,  as  appropriate. 

I 

Representatives  of  the  project's  software  engineering  group 
work  with  representatives  of  the  other  engineering  groups 
to  monitor  and  coordinate  technical  activities  and  resolve 
technical  issues.  (L3-87,  A2) 

□  The  representatives  of  these  groups  monitor  and 

coordinate  technical  activities  by; 

□  coordinating  the  specification  and  providing  the 
technical  review  and  approval  of  the  system 
requirements  and  system  design; 

□  providing  the  project-level  technical  review  and 
analysis  needed  to  manage  and  control  changes  to 
the  system  requirements  and  project-level  objectives 
throughout  the  project's  life  cycle; 

□  tracking  and  reviewing  the  design  and  development 
activities  for  hardware,  software,  and  other  system 
components;  and 

□  assessing,  developing  recommendations  for,  and 
tracking  technical  risks  that  involve  more  than  one 
engineering  group. 

□  The  representatives  of  the  groups  handle  technical 

issues  by; 

□  resolving  project-level  conflicts  and  clarifying 
system  requirements  and  design  issues; 

□  developing  joint  recommendations  to  resolve 
problems;  and 

□  addressing  process  issues  that  span  the  engineering 
groups  of  the  project. 

Continued  on  next  page 
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1C  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  describes  the  activities  associated  with  die  intergroup  coordination 
process,  continued  from  the  previous  page. 


V 

Activities 

References 

A  documented  plan  is  used  to  communicate  intergroup 
commitments  and  to  coordinate  and  track  the  work 
performed.  (L3-88,  A3) 

Critical  dependencies  between  engineering  groups  are 
identified,  negotiated,  and  tracked  according  to  a 
documented  procedure.  (L3-89,  A4) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Work  products  produced  as  input  to  other  engineering 
groups  are  reviewed  by  representatives  of  the  receiving 
groups  to  ensure  that  the  work  products  meet  their  needs. 
(L3-90,  A5) 

Intergroup  issues  not  resolvable  by  the  individual 
representatives  of  the  project  engineering  groups  are 
handled  according  to  a  documented  procedure.  (L3-9U, 

A6) 

Representatives  of  the  project  engineering  groups  conduct 
periodic  technical  reviews  and  interchanges.  (L3-90,  A7) 

[Refer  to  IC  Process  Reviews  and  Audits  for  additional 
information.] 

Measurements  are  made  and  used  to  determine  the  status  of 
the  intergroup  coordination  activities.  (L3-91,  Ml) 

The  activities  for  intergroup  coordination  are  reviewed  with 
senior  management  on  a  periodic  basis.  (L3-91,  VI) 

The  activities  for  intergroup  coordination  are  reviewed  with 
the  project  manager  on  both  a  periodic  and  event-driven 
basis.  (L3-92,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  intergroup  coordination 
and  reports  the  results.  (L3-92,  V3) 

[Refer  to  IC  Process  Reviews  and  Audits  for  additional 
information.] 
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1C  Process  -  Outputs 


Outputs 


The  table  below  lists  the  outputs  produced  by  the  intergroup  coordination  process. 


Output 

Org.  Outputs 

References 

Acceptance  criteria  for  each  product 
delivered  to  the  customer.  (L3-87,  Al,  3) 

Acceptance  criteria  for  each  product 
delivered  to  the  end  user.  (L3-87,  Al,  3) 

Agreement  for  each  critical  dependency. 
(L3-89,  A4,  4) 

Availability  dates  of  critical  dependency 
items.  (L3-89,  A4,  3) 

Commitments.  (L3-90,  A7,  4) 

Critical  characteristics  of  the  customer’s 
requirements.  (L3-87,  Al,  1) 

Critical  characteristics  of  the  end  users' 
requirements.  (L3-87,  Al,  1) 

Critical  dependencies.  (L3-87,  Al,  2) 

Intergroup  issues  not  resolvable  by  the 
individual  representatives  of  the  project 
engineering  groups.  (L3-90,  A6) 

Intergroup  issues.  (L3-92,  V3,  2) 

Joint  recommendations  to  resolve 
problems.  (L3-88,  A2,  2.2) 

Measurements  to  determine  the  status  of 
the  intergroup  coordination  activities.  (L3- 
91,  Ml) 

Need  dates  of  critical  dependency -items. 
(L3-89,  A4,  3) 

Plan  used  to  communicate  intergroup 
commitments  and  to  coordinate  and  track 
the  work  performed.  (L3-88,  A3) 

Problems  (actual  and  potential).  (L3-89, 
A4,  5.3) 

Process  issues.  (L3-88,  A2,  2.3) 

(Project  engineering)  groups’  interpretation 
and  implementation  of  the  technical 
requirements.  (L3-90,  A7,  3) 

Project-level  conflicts.  (L3-88,  A2,  2.1) 

Project-level  objectives.  (L3-84,  Cl,  1) 

Continued  on  next  page 
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1C  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  outputs  produced  by  the  intergroup  coordination  process, 
continued  from  the  previous  page. 


V 

Output 

Org.  Outputs 

References 

Recommendations  for  technical  risks  (that 
involve  more  than  one  engineering  group). 
(L3-88,  A2,  1.4) 

Results  of  software  quality  assurance 
group  reviews  and/or  audits.  (L3-92,  V3) 

Specification  of  the  system  design.  (L3- 
87,  A2,  I.l) 

Specification  of  the  system  requirements. 
(L3-87,  A2,  1.1) 

System  design.  (L3-87,  A2,  1.1) 

System  design  issues.  (L3-88,  A2,  2.1) 

System  requirements  issues.  (L3-88,  A2, 
2.1) 

System  requirements.  (L3-84,  Cl,  1) 

Technical  issues.  (L3-87,  A2) 

Work  products  produced  as  input  to  other 
engineering  groups.  (L3-90,  A5) 
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Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  intergroup  coordination  process. 


Output 

State 

References 

Acceptance  criteria 
for  each  product 
delivered  to  the 
customer 

are  documented.  (L3-87,  Al,  3) 

Acceptance  criteria 
for  each  product 
delivered  to  the  end 
user 

are  documented.  (L3-87,  Al,  3) 

Agreement  for  each 
critical  dependency 

□  is  documented.  (L3-89,  A4,  4) 

□  is  reviewed.  (L3-89,  A4,  4) 

□  is  approved  by  both  the 
receiving  group  and  the  group 
responsible  for  providing  the 
critical  dependency  item.  (L3- 
89,  A4,  4) 

Availability  dates  of 
critical  dependency 
items 

□  are  tied  to  the  project  schedule. 
(L3-89,  A4,  3) 

□  are  tied  to  the  software  schedule. 
(L3-89,  A4,  3) 

Critical  characteristics 
of  the  customer's 
requirements 

are  defined.  (L3-87,  Al,  1) 

Critical  characteristics 
of  the  end  users’ 
requirements 

are  defined.  (L3-87,  Al,  1) 

Continued  on  next  page 
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1C  Process  -  Exit  Criteria,  continued 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 

exit  criteria,  to  exit  the  intergroup  coordination  process,  continued  from  the  previous  page, 

continued _ 


V 

Output 

State 

References 

Critical  dependencies 

□  are  negotiated  (between  the 
software  engineering  group, 
other  engineering  groups, 
customers,  and  end  users).  (L3- 
87,  Al,  2) 

□  (between  engineering  groups) 
are:  (L3-89,  A4) 

□  identified, 

□  negotiated,  and 

□  tracked  according  to  a 
documented  procedure., 

□  are  explicitly  defined,  including: 
(L3-89.  A4,  1) 

□  the  item  to  be  provided, 

□  who  will  provide  it, 

□  when  it  will  be  provided,  and 

□  the  criteria  for  acceptance. 

□  are  negotiated  between  the 
software  engineering  group  and 
other  engineering  groups  in  the 
project  and  organization.  (L3- 
89,  A4,  2) 

□  cu-e  tracked  on  a  regular  basis 
and  corrective  actions  are  taken 
when  appropriate.  (L3-89,  A4, 

5) 

Intergroup  issues  not 
resolvable  by  the 

individual 

representatives  of  the 
project  engineering 
groups 

are  handled  according  to  a 
documented  procedure.  (L3-90,  A6) 

Joint 

recommendations  to 
resolve  problems 

are  developed  by  the  representatives 
of  the  (software  engineering  and 
other  engineering)  groups  to  handle 
technical  issues.  (L3-88,  A2,  2.2) 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L3-Process-165 


1C  Process  -  Exit  Criteria,  continued 


Oui,)ut-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  intergroup  coordination  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Measurements  (to 
determine  the  status 
f  the  intergroup 
coordination 
activities) 

□  are  made.  (L3-91,  Ml) 

□  are  used.  (L3-91,  Ml) 

Need  dates  of  critical 
dependency  items 

□  are  tied  to  the  pioject  schedule. 
(L3-89,  A4,  3) 

□  are  tied  to  the  software  schedule. 
(L3-89,  A4,  3) 

Plan  used  to 
communicate 
intergroup 
commitments  and  to 
coordinate  and  track 
the  work  performed 

□  is  the  baseline  for:  (L3-88,  A3, 

1) 

□  the  project  schedule, 

□  the  contractual  and  technical 
aspects  of  the  project,  and 

□  the  assignment  of 
responsibilities  to  the 
engineering  groups. 

□  is  used  to  coordinate  activities 
between  the  different 
engineering  groups.  (L3-88,  A3, 
2) 

□  is  readily  available  to  the 
members  of  all  engineering 
groups.  (L3-88,  A3,  3) 

□  is  updated  to  incorporate  ali 
intergroup  commitments  and 
changes  to  these  commitments. 
(L3-88,  A3,  4) 

□  is  updated  as  the  work  progresses 
to  reflect  progress  and  plan 
changes  at  the  project  level, 
particularly  when  major  p.’-oject 
milestones  are  completed  and 
when  plans  change  significantly. 
(L3-88,  A3,  5) 

Output  continued  on  next  page 
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1C  Process  >  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  intergroup  coordination  process,  continued  from  the  previous  page. 


Output 

State 

References  j 

— 

Output  continued  from  previous  page 

Plan  used  to 
communicate 
intergroup 
commitments  and  to 
coordinate  and  track 
the  work  performed, 
continued 

□  is  reviewed  by  all  engineering 
groups  and  the  project 
manager.  (L3-89,  A3,  6) 

□  is  agreed  to  by  ail  engineering 
groups  and  the  project 
manager.  (L3-89,  A3,  6) 

Problems  (actual  and 
potential) 

are  reported  to  the  appropriate 
managers.  (L3-89,  A4,  5.3) 

Process  issues 

are  addressed  by  representatives  of 
the  project's  software  engineering 
group  and  representatives  of  the 
other  engineering  groups.  (L3-88, 
A2,  2.3) 

(Project  engineering) 
groups'  interpretation 
and  implementation 
of  the  technical 
requirements 

conform  to  the  system  requirements. 
(L3-90,  A7,  3) 

Project-level  conflicts 

are  resolved  by  representatives  of 
the  project's  software  engineering 
group  and  representatives  of  the 
other  engineering  groups.  (L3-88, 
A2,  2.1) 

Project-level 

objectives 

□  are  defined.  (L3-84,  Cl,l) 

□  are  reviewed  by  all  affected 
groups.  (L3-84,  Cl,]) 

Recommendations 
for  technical  risks 
that  involve  more 
than  one  engineering 
group 

are  developed.  (L3-88,  A2,  1 .4) 

Results  of  software 
quality  assurance 
group  reviews  and/or 
audits 

are  reported.  (L3-92,  V3) 
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1C  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  intergroup  coordination  process,  continued  from  the  previous  page. 


Output 

State 

References 

Specification  of  the 
system  design 

is  coordinated  by  representatives  of 
the  project's  software  engineering 
group  and  representatives  of  the 
other  engineering  groups.  (L3-87, 
A2,  1.1) 

Specification  of  the 
system  requirements 

is  coordinated  by  representatives  of 
the  project's  software  engineering 
group  and  representatives  of  the 
other  engineering  groups.  (L3-87, 
A2,  I.l) 

System  design 

□  is  technically  reviewed  by 
representatives  of  the  project's 
software  engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-87, 

A2,  1.1) 

□  is  approved  by  representatives  of 
the  project’s  software 
engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-8/, 

A2,  1.1) 

□  is  tracked  by  representatives  of 
the  project's  software 
engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-88, 

A2,  1.3; 

System  design  issues 

are  clarified  by  representatives  of 
the  project’s  software  engineering 
group  and  representatives  of  the 
other  engineering  group.s.  (L3-88, 
A2,  2.1) 
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L3-Process-168 


CMU/SEI-94-HB-1 


1C  Process  -  Exit  Criteria,  Continued 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 

exit  criteria,  to  exit  the  intergroup  coordination  process,  continued  from  the  previous  page, 

continued  _ 


Output 

State 

References 

System  requirements 

□  are  defined.  (L3-84,  Cl,  1) 

□  are  reviewed  by  all  affected 
groups.  (L3-84,  Cl,  1) 

□  are  established  by  the  software 
engineering  group  and  the  other 
engineering  groups,  by 
participating  with  the  customer 
and  end  users,  as  appropriate. 
(L3-86,  Al) 

□  are  technically  reviewed  by 
representatives  of  the  project’s 
software  engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-87, 

A2,  1.1) 

□  are  approved  by  .epresentatives 
of  the  project's  software 
engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-87, 

A2,  1.1) 

□  are  clarified  by  representatives 
of  the  project's  software 
engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-88, 

A2,  2,1) 

System  requirements 
issues 

I 

are  clarified  by  representatives  of 
the  project’s  software  engineering 
group  and  representatives  of  the 
other  engineering  groups.  (L3-88, 
A2,  2.1) 

Continued  on  next  page 
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1C  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  intergroup  coordination  process,  continued  from  the  previous  page. 


Output 

State 

References 

Technical  issues 

□  are  resolved  by  representatives 
of  the  project's  software 
engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-87, 

A2) 

□  are  handled  by  representatives 
of  the  project's  software 
engineering  group  and 
representatives  of  the  other 
engineering  groups.  (L3-88, 

A2,  2) 

□  are  reviewed  by  representatives 
of  the  project  engineering 
groups.  (L3-90,  A7,  5) 

Work  products 

□  are  reviewed  by  representatives 
of  the  receiving  groups  to  ensure 
that  the  work  products  meet  their 
needs.  (L3-90,  A5) 

□  are  reviewed  and/or  audited  by 
the  software  quality  assurance 
group.  (L3-92,  V3) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  intergroup  coordination  process. 


Condition 

References 

The  engineering  groups  coordinate  their  plans  and 
activities.  (L3-84,  Cl,  2) 

The  software  engineering  group  and  the  other  engineering 
groups  participate  with  the  customer  and  end  users,  as 
appropriate,  to  establish  the  system  requirements.  (L3-86, 
Al) 

Continued  on  next  page 
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1C  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  intergroup  coordination  process,  continued  from  the  previous  page. 


V 

Condition 

References 

Representatives  of  the  project’s  software  engineering  group 
work  with  representatives  of  the  other  engineering  groups 
to  monitor  and  coordinate  technical  activities  and  resolve 
technical  issues.  (L3-87,  A2) 

The  representatives  of  these  groups  monitor  and  coordinate 
technical  activities  by;  (13-87,  A2,  1) 

□  coordinating  the  specification  and  providing  the 
technical  review  and  approval  of  the  system 
requirements  and  system  design; 

□  providing  the  project-level  technical  review  and  analysis 
needed  to  manage  and  control  changes  to  the  system 
requirements  and  project-level  objectives  throughout  the 
project's  life  cycle; 

□  tracking  and  reviewing  the  design  and  development 
activities  for  hardware,  softv/are,  and  other  system 
components;  and 

□  assessing,  developing  recommendations  for,  and  tracking 
technical  risks  that  involve  more  than  one  engineering 
group. 

A  documented  plan  is  used  to  communicate  intergroup 
commitments  and  to  coordinate  and  track  the  work 
performed.  (L3-88,  A3) 

Representatives  of  the  project  engineering  groups  conduct 
periodic  technical  reviews  and  interchanges.  (L3-90,  A7) 

The  activities  for  intergroup  coordination  are  reviewed  with 
senior  manage.tnent  on  a  periodic  basis.  (L3  91,  V]) 

The  activities  for  intergroup  coordination  are,  reviewed  with 
the  project  manager  on  both  a  periodic  and  event-driven 
basis.  (L3-92,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  intergroup  coordination 
and  reports  the  results.  (L3-92,  V3) 
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iC  Process  «  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  intergroup 
coordination  process. 


,  I 

! 

Review  or  Audit 

Review 

Participants 

References 

The  system  requirements  and  project-level 
objectives  for  the  project  are  defined  and 
reviewed  by  all  afl'ected  groups.  (L3-84, 

Cl,  1) 

Affected 

groups 

Representatives  of  the  project's  software 
engineering  group  work  with 
representatives  of  the  other  engineering 
groups  to:  (L3-87,  A2) 

□  Provide  the  technical  review  and 
approval  of  the  system  requirements 
and  system  design.  (L3-8%  A2,  1.1) 

□  Provide  the  project-level  technical 
review  and  analysis  needed  to  manage 
and  control  changes  to  the  system 
requirements  and  project-level 
objectives  throughout  the  project's  life 
cycle.  (L3-87,  A2,  1.2) 

□  Track  and  review  the  design  and 
development  activities  for  hardware, 
software,  and  other  system 
components.  (L3-88,  A2,  1 .3) 

Representa¬ 
tives  of  the 
project's 
software 
engineering 
group 

Representa¬ 
tives  of  the 
other 

engineering 

groups 

— 

The  documented  plan  used  to 
communicate  intergroup  commitments  and 
to  coordinate  and  track  the  work 
performed  is  reviev'ed  and  agreed  to  by  all 
engineering  groups  and  the  project 
manager.  (L3-89,  A3,  6) 

Engineering 

groups 

Project 

manager 

The  agreement  for  each  critical 
dependency  is  documented,  reviewed,  and 
approved  by  both  the  receiving  group  and 
the  group  responsible  for  providing  the 
critical  dependency  item.  (L3-89,  A4, 4) 

Receiving 

group 

Group 

responsible  for 
providing  the 
critical 
dependency 
item 

Work  products  produced  as  input  to  other 
engineering  groups  are  reviewed  by 
representatives  of  the  receiving  groups  to 
ensure  that  the  work  products  meet  their 
needs.  (L3-90,  A5) 

Representa¬ 
tives  of  the 
receiving 
groups 

Continued  on  next  page 
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1C  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  intergroup 
coordination  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

Representatives  of  the  project  engineering 

groups  conduct  periodic  technical  reviews 

and  interchanges.  (L3-90,  A7) 

In  these  meetings,  the  participants: 

□  Provide  visibility  of  the  needs  and 
desires  of  the  customer  and  end  users, 
as  appropriate. 

□  Monitor  the  technical  activities  of  the 
project. 

□  Ensure  that  the  groups’  interpretation 
and  implementation  of  the  technical 
requirements  conform  to  the  system 
requirements. 

□  Review  the  commitments  to  determine 
whether  they  are  being  met. 

□  Review  the  technical  risks  and  other 
technical  issues. 

Representa* 
tives  of  the 
project 
engineering 
groups 

The  activities  for  intergroup  coordination 
are  reviewed  with  senior  management  on  a 
periodic  basis.  (L3-91,  VI) 

Senior 

management 

The  activities  for  intergroup  coordination 
are  reviewed  with  the  project  manager  on 
both  a  periodic  and  event-driven  basis. 
(L3-92,  V2) 

Project 

manager 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  intergroup  coordination  and 
reports  the  results.  (L3-92,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify: 

□  The  procedure  for  identifying, 
negotiating,  and  tracking  critical 
dependencies  between  the  project 
engineering  groups. 

□  The  handling  of  intergroup  issues. 

Software 

quality 

assurance 

group 
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1C  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


There  are  no  work  products  that  are  recommended  to  be  managed  and  controlled 
in  the  intergroup  coordination  process. 
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1C  Process  -  Measurements 


Measurements  The  table  below  lists  the  measurements  recommended  for  the  intergroup 
coordination  process. 


Measurements 


Measurements  to  determine  the  status  of  the  intergroup 

coordination  activities.  (L3-91,  Ml) 

Examples  of  measurements  include; 

□  Actual  effort  and  other  resources  expended  by  the 
software  engineering  group  for  support  to  other 
engineering  groups. 

□  Actual  effort  and  other  resources  expended  by  the  other 
engineering  groups  in  support  of  the  software 
engineering  group. 

□  Actual  completion  of  specific  tasks  and  milestones  by 
the  softwaie  engineering  group  to  support  the  activities 
of  other  engineering  groups. 

□  Actual  completion  of  specific  tasks  and  milestones  by 
the  other  engineering  groups  to  support  the  activities  of 
the  software  engineering  group. 


References 
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1C  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  intergroup  coordination  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


Documented  Procedure(s) 

References 

Critical  dependencies  between  engineering  groups  are 
identified,  negotiated,  and  tracked  according  to  a 
documented  procedure.  (L3-89,  A4) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Intergroup  issues  not  resolvable  by  the  individual 
representatives  of  the  project  engineering  groups  are 
handled  according  to  a  documented  procedure.  (L3-90, 

A6) 
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1C  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  intergroup  coordination 
process. 


~T 

Training 

References 

All  managers  in  the  organization  receive  required  training 
in  teamwork.  (L3-85,  Ab3) 

All  task  leaders  in  each  engineering  group  receive 
orientation  in  the  processes,  methods,  and  standards  used  by 
the  other  engineering  groups.  (L3-86,  Ab4) 

The  members  of  the  engineering  groups  receive  orientation 
in  working  as  a  team.  (L3-86,  Ab5) 
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1C  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  intergroup  coordination 
process. 


T 

Tools 

References 

Support  tools  used  by  the  different  engineering  groups. 
(L3-85,  Ab2) 

Examples  of  support  tools  include: 

□  word  processing  systems, 

□  database  systems, 

□  graphics  tools, 

□  spreadsheet  programs, 

□  problem  tracking  packages,  and 

□  library  management  tools. 
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Peer  Reviews  (PR)  Process 
PR  Process  -  Overview 


PR  process 
purpose 


PR  process 
description 


Section 

overview 


The  purpose  of  Peer  Reviews  is  to  remove  defects  from  the  software  work  products 
early  and  efficiently.  An  important  corollary  effect  is  to  develop  a  better 
understanding  of  the  software  work  products  and  of  defects  that  might  be 
prevented.  (L3-93) 


Peer  Reviews  involve  a  methodical  examination  of  software  work  products  by  the 
producers'  peers  to  identify  defects  and  areas  where  changes  are  needed.  The 
specific  products  that  will  undergo  a  peer  review  are  identified  in  the  project's 
defined  software  process  and  scheduled  as  part  of  the  software  project  planning 
activities,  as  described  in  Integrated  Software  Management. 

This  key  process  area  covers  the  practices  for  performing  peer  reviews.  The 
practices  identifying  the  specific  software  work  products  that  undergo  peer  review 
are  contained  in  the  key  process  areas  that  describe  the  development  and 
maintenance  of  each  software  work  product.  (L3-93) 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L3-Process-180 

Entr,  Criteria 

Description  of  when  the  process  can  start. 

L3-Process-182 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L3-Process-183 

Activities 

Description  of  the  activities  of  the 
process. 

L3-Process-I84 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L3-Process-185 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L3-Process- 1 86 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L3-Process-188 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L3-Process-189 

Measurements 

Description  of  process  measurements. 

L3-Proces.s-190 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L3-Process-191 

Training 

List  of  training. 

L3-Process-192 

Tools 

List  of  tools. 
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PR  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the  peer 
reviews  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Checklist 

developers’ 

peers 

The  checklists  are  reviewed  by  the  checklist 
developers'  peers  and  potential  users.  (L3- 
98,  A2,  5.2) 

Checklist 
potential  users 

The  checklists  are  reviewed  by  the  checklist 
developers’  peers  and  potential  users.  (L3- 
98,  A2,  5.2) 

Management 

Results  of  the  peer  reviews  are  not  used  by 
management  to  evaluate  the  performance 
of  individuals.  (L3-94,  Cl,  5) 

Manager 

Issues  in  satisfying  these  (readiness  and 
completion)  criteria  (for  the  peer  reviews) 
are  reported  to  the  appropriate  managers. 
(L3-98,  A2,  4.1) 

Peer  review 
leader 

□  Peer  reviews  are  led  by  trained  peer 
review  leaders.  (L3-94,  Cl,3) 

□  Peer  review  leaders  receive  required 
training  in  how  to  lead  peer  reviews. 
(L3-95,  Ab2) 

□  Peer  reviews  are  planned  and  led  by 
trained  peer  review  leaders.  (L3-97, 
A2,  1) 

□  The  peer  review  leaders  are 
adequately  trained  for  their  roles.  (L3- 
100,  VI,  2) 

Continued  on  next  page 
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PR  Process  ■  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the  peer 
reviews  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Reviewer 

□  Reviewers  who  participate  in  peer 
reviews  receive  required  training  in  the 
objectives,  principles,  and  methods  of 
peer  reviews.  (L3-96,  Ab3) 

□  Review  materials  are  distributed  to  the 
reviewers  in  advance  so  they  can 
adequately  prepare  for  the  peer  review. 
(L3-97,  A2,  2) 

□  Reviewers  have  assigned  roles  in  peer 
reviews.  (L3-98,  A2,  3) 

□  The  reviewers  are  properly  trained  or 
experienced  in  their  roles.  (L3-100, 

VI,  3) 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  peer  reviews  and  reports  the 
results.  (L3-100,  VI) 
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PR  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  in  the  peer  reviews  process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  peer  reviews  process. 


V 

Condition 

References 

The  project  follows  a  written  organizational  policy  for 
performing  peer  reviews.  (L3-94,  Cl) 

[Refer  to  Level  3  Policies  for  additional  information 
regarding  PR  policy.] 

Adequate  resources  and  funding  are  provided  for 

performing  peer  reviews  on  each  software  work  product  to 

be  reviewed.  (L3-95,  Abl) 

Resources  and  funding  are  provided  to: 

□  Prepare  and  distribute  the  peer  review  materials. 

□  Lead  the  peer  review. 

□  Review  the  materials. 

□  Participate  in  the  peer  review  and  any  follow-up  reviews 
required  based  on  the  defects  identified  in  the  peer 
review. 

□  Monitor  the  rework  of  the  software  work  product  based 
on  the  defects  identified  in  the  peer  review. 

□  Collect  and  report  the  data  resulting  from  the  peer 
reviews. 

Peer  review  leaders  receive  required  training  in  how  to  lead 
peer  reviews.  (L3-95,  Ab2) 

Reviewers  who  participate  in  peer  reviews  receive  required 
training  in  the  objectives,  principles,  and  methods  of  peer 
reviews.  (L3-96,  Ab3) 
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PR  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  peer  reviews  process. 


Input 

Org.  Input 

References 

Checklists.  (L3-98,  A2,  5) 

Peer  review  materials  or  review  materials. 
(L3-95,  Abl,  1) 

Software  work  product(s).  (L3-94,  Cl,  4) 

Standard  set  of  software  work  products 
(identified  in  the  organization’s  standard 
software  process)  that  will  undergo  peer 
review.  (L3-94,  Cl,  1) 
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PR  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  peer  reviews  process. 


Activities 

References 

Peer  reviews  are  planned,  and  the  plans  are  documented. 
(L3-97,  Al) 

Peer  reviews  arc  perfonned  according  to  a  documented 
procedure.  (L3-97,  A2) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 

Data  on  the  conduct  and  results  of  the  peer  reviews  are 
recorded.  (L3-99,  A3) 

Measurements  are  made  and  used  to  determine  the  status  of 
the  peer  review  activities.  (L3-99,  Ml) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  peer  reviews  and  reports 
the  results.  (L3-100,  VI) 

[Refer  to  PR  Process  Reviews  and  Audits  for  additional 
information.] 
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PR  Process  -  Output? 


Outputs  The  table  below  lists  the  recommended  outputs  produced  by  the  peer  reviews 

process. 


Output 

Org.  Outputs 

References 

Actions  identified  in  the  peer  reviews.  (L3- 
98,  A2,  6) 

Checklists.  (L3-98.  A2,  5.1) 

Completion  criteria  for  the  peer  reviews. 
(L3-98,  A2,  4) 

Criteria  for  the  review  of  the  software  work 
products.  (L3-98,  A2,  5) 

Data  on  the  conduct  of  the  peer  reviews. 
(L3-99,  A3) 

Data  resulting  from  the  peer  reviews.  (L3- 
95,  Abl,  6) 

Defects  identified  in  the  peer  review.  (L3- 
95,  Abl,  4) 

Issues  in  satisfying  (readiness  and 
completion)  criteria  for  the  peer  reviews. 
(L3-98,  A2,  4.1) 

Measurements  (to  determine  the  status  of 
the  peer  review  activities).  (L3-99,  Ml) 

Plans  for  peer  reviews.  (L3-97,  Al) 

Readiness  criteria  for  the  peer  reviews. 
(L3-98,  A2,  4) 

Results  of  peer  reviews.  (L3-94,  Cl,  5) 

Results  of  SQA  group  reviews  and/or 
audits  of  the  activities  and  work  products 
for  peer  reviews.  (L3-100,  VI) 

Schedule  of  peer  reviews.  (L3-97,  Al,  2) 

Software  work  products  that  will  undergo 
peer  review.  (L3-94,  Cl,2) 
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PR  Process  -  Exit  Criteria 


Output-based 
‘ntry  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  th^  table  below 
to  exit  the  peer  reviews  process. 


Output 

State 

References 

Actions  identified  in 
the  peer  reviews 

are  tracked  '.mtil  they  are  resolved. 
(L3-98.  A2,  6) 

Checklists 

□  are  used  to  identify  criteria  for 
the  review  of  the  software  work 
products  in  a  consistent  manner. 
(1,3-98,  A2.  5) 

□  are  tailored  to  ihe  specific 
type  of  work  product  and 
peer  review.  (L3-98,  A2, 

5.1) 

□  are  reviewed  by  the  checklist 
developers'  peers  and 
potential  users.  (L3-98,  A2, 

5.2) 

Completion  criteria 
for  the  peer  reviews 

□  are  specified.  (L3-98,  A2,  4) 

□  are  enforced.  (L3-98,  A2,  4) 

Data  on  the  conduct 
of  the  peer  reviews 

are  recorded.  (L3-99,  A3) 

Data  resulting  from 
the  peer  reviews 

□  are  collected.  (L3-95,  Abl,  6) 

□  are  reported.  (L3-95,  Abl,  6) 

□  are  recorded.  (L3-99,  A3) 

Issues  in  satisfying 
(readiness  and 
completion)  criteria 
for  the  peer  reviews 

are  reported  to  the  appropriate 
managers.  (L3-98,  A2,  4.1) 

Measurements  (to 
determine  the  status 
of  the  peer  review 
activities) 

□  are  made.  (L3-99,  Ml) 

□  are  used.  (L3-99,  Ml) 

Plans  for  peer  reviews 

□  are  documented.  (L3-97,  Al) 

□  identify  the  software  work 
products  that  will  undergo  peer 
review.  (L3-97,  Al,  1) 

□  specify  the  schedule  of  peer 
reviews.  (L3-97,  Al,  2) 

Readiness  criteria  for 
the  peer  reviews 

□  are  specified.  (L3-98,  A2,  4) 

□  are  enforced.  (L3-98,  A2,  4) 

Continued  on  next  page 
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PR  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  peer  reviews  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Results  of  the  peer 
reviews 

arc  not  used  by  management  to 
evaluate  the  performance  of 
individuals.  (L3-94,  Cl,  5) 

Results  of  SQA 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  peer  reviews 

are  reported.  (L3-100,  VI) 

Schedule  of  peer 
reviews 

are  specified  in  ihe  plans  for  peer 
reviews.  (L3-97,  Al,2) 

Software  work 
products  that  will 
undergo  peer  review 

□  are  identified  by  each  project. 
(L3-94,  Cl,  2) 

□  include  the  set  identified  in  the 
organization’s  standard  software 
process.  (L3-97,  Al,  1.1) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  peer  reviews  process. 


Condition 

References 

Peer  reviews  are  planned,  and  the  plans  are  documented. 
(L3-97,  Al) 

Peer  reviews  are  performed  according  to  a  documented 
procedure..  (L3-97,  A2) 

Data  on  the  conduct  and  results  of  the  peer  reviews  are 
recorded.  (L3-99,  A3) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  peer  reviews  and  reports 
the  results.  (L3-100,  VI) 
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PR  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  peer  reviews 
process. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  checklists  are  reviewed  by  the  checklist 
developers'  peers  and  potential  users. 
(L3-98,  A2,  5.2) 

Checklist 

developers' 

peers 

Checklist 
potential  users 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  peer  reviews  and  reports  the 
results.  (L3-100,  VI) 

At  a  minimum,  the  reviews  and/or  audits 
verify  that: 

□  The  planned  peer  reviews  are 
conducted. 

□  The  peer  review  leaders  are 
adequately  trained  for  their  roles. 

□  The  reviewers  are  properly  trained  or 
experienced  in  their  roles. 

□  The  process  for  preparing  for  the  peer 
reviews,  conducting  the  peer  reviews, 
and  performing  the  follow-up  actions 
are  followed. 

□  Reporting  of  peer  review  data  is 
complete,  accurate,  and  timely. 

Software 

quality 

assurance 

group 

: 
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PR  Process  -  Work  Products  Managed  and  Controlled 


Work  products  There  are  no  work  products  recommended  to  be  managed  and  controlled  in  the 

managed  and  peer  reviews  process. 

controlled 
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PR  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  peer  reviews  process. 


Measurements 

References 

Data  on  the  conduct  and  results  of  the  peer  reviews.  (L3-99, 
A3) 

Measurements  to  determine  the  status  of  the  peer  review 

activities.  (L3-99,  Ml) 

Examples  of  measurements  include:. 

□  Number  of  peer  reviews  performed  compared  to  the 
plan. 

□  Overall  effort  expended  on  peer  reviews  compared  to  the 
plan. 

□  Number  of  work  products  reviewed  compared  to  the 
plan. 

L3-Process-190 


CMU/SEI-94-HB-1 


PR  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  peer  reviews  process  recommended  to  be 
performed  according  to  a  documented  procedure. 


T 

Documented  Procedure(s) 

References 

Peer  reviews  are  performed  according  to  a  documented 
procedure.  (L3-97,  A2) 

[Refer  to  Level  3  Procedure  Checklists  for  additional 
information.] 
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PR  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  peer  reviews  process. 


V 

Training 

References 

Peer  review  leaders  receive  required  training  in  how  to  lead 
peer  reviews.  (L3-95,  Ab2) 

Reviewers  who  participate  in  peer  reviews  receive  required 
training  in  the  objectives,  principles,  and  methods  of  peer 
reviews.  (L3-96,  Ab3) 
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PR  Process  -  Tools 


Tools 


There  are  no  tools  recommended  in  the  peer  reviews  process. 
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Level  3  Procedure  Checklists 
Overview 


Introduction 


Purpose 


In  this  section 


This  section  describes  all  the  explicit  documented  procedures  in  the  Capability 
Maturity  Model  for  maturity  level  3. 


The  purpose  of  the  procedure  checklists  is  to  provide: 

•  Guidance  in  identifying  which  procedures  are  recommended  by  the  CMM  at 
level  3. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  procedures  to 
determine  if  those  procedures  are  consistent  with  the  CMM  at  level  3. 

•  Information  that  can  be  used  to  develop  software  procedures  that  are  consistent 
with  the  CMM  at  level  3. 


This  section  covers  the  following  documented  procedures: 


CMM  Level  3  Procedures 

See  Page 

Organization  process  focus  procedures 

L3-Procedures-2 

Organization  process  definition  procedure 

L3-Procedures-3 

Training  program  procedure 

L3-Procedures-4 

Integrated  software  management  procedures 

L3-Procedures-5 

Software  product  engineering  procedures 

L3-Procedures-12 

Intergroup  coordination  procedures 

L3-Procedures-13 

Peer  reviews  procedure 

L3-Procedures-14 

Note:  The  CMM  does  not  recommend  that  any  activities  be  performed  according 
to  a  documented  procedure  for  the  organization  process  focus  and 
software  product  engineering  processes. 
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Organization  Process  Focus  (OPF)  Procedures 


Documented 

procedures 


The  CMM  does  not  recommend  that  any  activities  be  performed  according  to  a 
documented  procedure  for  the  organization  process  focus  process. 
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Organization  Process  Definition  (OPD)  Procedure 


Documented 

procedure 


The  table  below  lists  the  recommended  documented  procedure  for  the 
organization  process  definition  process. 


V 

Documented  Procedure 

References 

The  organization's  standard  software  process  is  developed 

and  maintained  according  to  a  documented  procedure.  (L3- 

15,  Al) 

This  procedure  typically  specifies  that: 

□  The  organization’s  standard  software  process  satisfies  the 
software  policies,  process  standards,  and  product 
standards  imposed  on  the  organization,  as  appropriate. 

□  The  organization's  standard  software  process  satisfies  the 
software  process  and  product  standards  that  are 
commonly  imposed  on  the  organization's  projects  by 
their  customers,  as  appropriate. 

□  State-of-the-practice  software  engineering  tools  and 
methods  are  incorporated  into  the  organization's 
standard  software  process,  as  appropriate. 

□  The  internal  process  interfaces  between  the  software 
disciplines  are  described. 

□  The  external  process  interfaces  between  the  software 
process  and  the  processes  of  other  affected  groups  are 
described. 

□  Changes  proposed  for  the  organization's  standard 
software  process  are  documented,  reviewed,  and 
approved  by  the  group  responsible  for  the 
organization's  software  process  activities  (e.g., 
software  engineering  process  group)  before  they  are 
incorporated. 

□  Plans  for  introducing  changes  to  the  software  process  of 
ongoing  projects  are  defined  as  appropriate. 

□  The  description  of  the  organization's  standard  software 
process  undergoes  peer  review  when  initially  developed 
and  whenever  significant  changes  or  additions  are  made. 

□  The  description  of  the  organization’s  standard  software 
process  is  placed  under  configuration  management. 
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Training  Program  (TP)  Procedure 


Documented 

procedure 


The  table  below  lists  the  recommended  documented  procedure  for  the  training 
program  process. 


V 

Documented  Procedure 

References 

The  organization's  training  plan  is  developed  and  revised 

according  to  a  documented  procedure.  (L3-30,  A2) 

This  procedure  typically  specifies  that: 

□  The  plan  uses  the  software  projects'  training  needs 
identified  in  their  training  plans. 

□  The  specific  training  to  be  provided  is  identified  based 
on  the  skills  needed  by  the  organization  and  when  those 
skills  are  needed. 

□  The  organization's  training  plan  is  revised,  as 
appropriate,  to  incorporate  changes. 

□  The  organization's  training  plan  is  reviewed  by  the 
affected  individuals  when  it  is  initially  released  and 
whenever  major  revisions  are  made. 

□  The  organization's  training  plan  is  managed  and 
controlled. 

□  The  organization's  training  plan  is  readily  available  to 
the  affected  groups  and  individuals. 

L3-Procedures-4 
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Integrated  Software  Management  (ISM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  integrated 
software  management  process. 


Documented  Procedures 

References 

The  project's  defined  software  process  is  developed  by 
tailoring  the  organization's  standard  software  process 
according  to  a  documented  procedure.  (L3-41,  Al) 

This  procedure  typically  specifies  that; 

□  A  software  life  cycle  is: 

□  selected  from  among  those  approved  by  the 
organization,  to  satisfy  the  project's  contractual  and 
operational  constraints; 

□  modified,  if  necessary,  in  ways  permitted  by  the 
organization's  tailoring  guidelines  and  criteria;  and 

□  documented  according  to  the  organization's 
standards. 

□  The  description  of  the  project's  defined  software  process 
is  documented. 

□  Tailoring  of  the  organization’s  standard  software  process 
for  the  project  is  reviewed  by  the  group  responsible  for 
coordinating  the  organization’s  software  process 
activities  (e.g.,  software  engineering  process  group) 
and  approved  by  senior  management. 

□  Waivers  for  deviations  from  the  organization's 
standard  software  process  are  documented  and  are 
reviewed  and  approved  by  senior  management. 

□  Waivers  for  deviations  from  contractual  software  process 
requirements  are  documented  and  are  reviewed  and 
approved  by  senior  management  and  the  software 
project's  customer,  as  appropriate. 

□  The  description  of  the  project’s  defined  software  process 
is  managed  and  controlled. 

Continued  on  next  page 
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Integrated  Software  Management  (ISM)  Procedures,  continued 


Documented  The  table  below  lists  the  recommended  documented  procedures  for  the  integrated 

procedures,  software  management  process,  continued  from  the  previous  page. 

continued 


V 

Documented  Procedures 

References 

Each  project's  defined  software  process  is  revised  according 
to  a  documented  procedure.  (L3-43,  A2) 

Thi:-  procedure  typically  specifies  that: 

□  Changes  derived  from  the  following  are  documented 
and  systematically  reviewed: 

□  lessons  learned  from  monitoring  the  software 
activities  of  the  organization’s  projects, 

□  changes  proposed  by  the  software  project,  and 

□  process  and  work  product  measurement  data. 

□  Changes  to  the  project's  defined  software  process  are 
reviewed  and  approved  before  they  are  incorporated. 

The  project's  software  development  plan,  which  describes  the 
use  of  the  project's  defined  software  process,  is  developed 
and  revised  according  to  a  documented  procedure.  (L3-44, 
A3) 

Continued  on  next  page 
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Integrated  Software  Management  (ISM)  Procedures,  continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  integrated 
software  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

References 

The  size  of  the  software  work  products  (or  size  of  changes  to 
the  software  work  products)  is  managed  according  to  a 
documented  procedure.  (L3-47,  A6) 

This  procedure  typically  specifies  that: 

□  A  group  that  is  independent  of  the  software  engineering 
group  reviews  the  procedures  for  estimating  the  size  of 
the  software  work  products,  and  provides  guidance  in 
using  historical  data  from  the  organization's  software 
process  database  to  establish  credible  estimates. 

□  The  individuals  who  prepare  the  size  estimates 
ensure  that  the  procedures  and  data  used  in  the 
estimates  are  appropriate. 

□  When  the  validity  of  a  size  estimate  is  questioned,  a 
team  of  peers  and  experts  reviews  the  estimate. 

□  A  contingency  factor  is  applied  to  the  size  estimate  for 
each  software  element  identified  as  a  software  risk. 

□  The  rationale  for  the  contingency  is  documented. 

□  The  risks  associated  with  reducing  or  eliminating  the 
contingency  are  assessed  and  documented. 

□  Off-the-shelf  or  reusable  software  components  are 
identified. 

□  Reuse  measurements  account  for  the  reuse  of 
requirements,  design,  code,  test  plan,  and  test 
procedures,  etc. 

□  The  effort  to  modify  and  incorporate  reusable 
components  is  factored  into  the  size  estimates. 

□  Factors  which  could  significantly  affect  the  size  of  the 
software  work  products  are  identified  and  monitored 
closely. 

□  A  size  threshold  is  established  for  each  managed 
software  element  which,  when  projected  to  be  exceeded, 
requires  action. 

Continued  on  next  page 
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Integrated  Software  Management  (ISM)  Procedures,  Continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  integrated 
software  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

References 

The  project's  software  effort  and  costs  are  managed 

according  to  a  documented  procedure.  (L3-48,  A7) 

This  procedure  typically  specifies  that: 

□  Software  effort,  cost,  and  staffing  profile  models,  if  used, 
are  adapted  to  the  project  and  use  available  historical 
data  where  appropriate. 

□  Referenced  productivity  and  cost  data  are  adjusted  to 
incorporate  project  variables. 

□  The  overall  software  effort  and  cost  is  allocated  to 
individually  managed  tasks  or  stages  as  needed  to 
manage  the  effort  and  cost  effectively. 

□  When  the  software  effort  and  cost  status  is  reviewed  and 
the  estimates  are  revised,  actual  expenditures  over  time 
and  against  work  completed  are  compared  to  the 
software  development  plan  and  used  to  refine  the  effort 
and  cost  estimates  for  remaining  work. 

□  Parameter  values  of  the  models  used  in  estimating 
software  effort  and  costs  are  updated  whenever 
major  changes  are  made  to  the  software 
requirements. 

□  Actual  data  on  project  productivity  and  other  new 
software  costs  are  used  where  appropriate. 

□  An  effort  and  cost  threshold  is  established  for  each 
individually  managed  software  task  or  stage  which,  when 
projected  to  be  exceeded,  requires  action. 

Continued  on  next  page 
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Integrated  Software  Management  (ISM)  Procedures,  continued 


Documented  The  table  below  lists  the  recommended  documented  procedures  for  the  integrated 
procedures,  software  management  process,  continued  from  the  previous  page. 

continued  ^ _ _ 

V  Documented  Procedures  References 

The  project's  critical  computer  resources  are  managed 
according  to  a  documented  procedure.  (L3-50,  A8) 

This  procedure  typically  specifies  that; 

□  Estimates  for  the  project's  critical  computer  resources  are 
derived  based  on  historical  experience,  simulations, 
prototyping,  or  analysis,  as  appropriate. 

□  Sources  and  rationale  for  estimates  are  documented. 

□  Similarities  and  differences  between  the  project  and 
the  sources  for  historical  data  in  terms  of  application 
domain  and  design  approach  are  assessed  and 
recorded. 

□  The  reasoning  used  to  judge  the  credibility  of  the 
estimates  is  recorded. 

□  The  planned  computer  resources,  the  system 
requirements  allocated  to  software,  the  software 
requirements,  and/or  the  software  design  are  adjusted  to 
achieve  the  project’s  critical  computer  resource 
requirements. 

□  The  available  computer  resources  are  allocated  to  the 
software  components. 

□  The  available  capacity  for  the  critical  computer 
resources  provides  for  a  specified  reserve  capacity  when 
the  initial  estimates  are  made. 

□  A  threshold  is  established  for  each  critical  computer 
resource  which,  when  projected  to  be  exceeded,  requires 
action. 


Continued  on  next  page 
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Integrated  Software  Management  (ISM)  Procedures,  continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  integrated 
software  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

References 

The  critical  dependencies  and  cntical  paths  of  the  project’s 

software  schedule  are  managed  according  to  a  documented 

procedure.  (L3-51,  A9) 

This  procedure  typically  specifies  that; 

□  Milestones,  tasks,  commitments,  critical  dependencies, 
staffing,  costs,  and  reviews  are  allocated  in  the  schedule 
consistent  with  the  project's  defined  software  process. 

□  The  software  schedule  identifies  specific  tasks  and 
milestones  whose  completion  can  be  objectively 
determined  (i.e.,  a  binary  or  yes/no  determination). 

□  Critical  dependencies  are  defined,  negotiated,  and 
reflected  in  the  software  schedule. 

□  Schedule  critical  paths  are  defined  and  reflected  in  the 
software  schedule. 

□  The  software  project’s  critical  dependencies  and  schedule 
critical  paths  are  tracked  on  a  regular  basis. 

□  Specific  documented  threshold  criteria  are  established 
for  each  critical  path  which,  when  projected  to  be 
exceeded,  require  action. 

Continued  on  next  page 
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Integrated  Software  Management  (ISM)  Procedures,  continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  integrated 
software  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

References 

The  project's  software  risks  are  identified,  assessed, 

documented,  and  managed  according  to  a  documented 

procedure.  (L3-52,  AlO) 

This  procedure  typically  specifies  that: 

□  A  software  risk  management  plan  is  documented  and 
used  to  identify  and  manage  the  software  risks. 

□  Contingency  planning  is  based  on  the  project's  defined 
software  process  and  is  performed  throughout  the 
project's  software  life  cycle. 

□  Alternatives  for  each  software  risk  are  defined,  where 
possible,  along  with  criteria  for  selecting  among  the 
alternatives. 

□  The  initial  release  and  major  revisions  to  the  software 
risk  management  plan  undergo  peer  review. 

□  The  software  risk  management  plan  is  managed  and 
controlled. 

□  Software  risks  are  tracked,  reassessed,  and  replanned  at 
selected  project  milestones,  at  designated  risk 
checkpoints,  and  during  the  planning  of  significant 
changes  that  affect  the  software  project. 

□  Risk  priorities  and  software  risk  management  plans 
are  reviewed  and  revised  at  these  reassessment  points. 

□  Information  obtained  from  monitoring  the  risks  is 
used  to  refine  the  risk  assessments  and  software  risk 
management  plans. 

□  The  software  engineering  group  and  other  affected 
groups  and  individuals  are  included  in  the 
communications  on  the  software  risks,  the  software  risk 
management  plans,  and  the  results  of  risk  mitigation. 
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Software  Product  Engineering  (SPE)  Procedures 


Documented 

procedures 


The  CMM  does  not  recommend  that  any  activities  be  performed  according  to  a 
documented  procedure  for  the  software  product  engineering  process. 
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Intergroup  Coordination  (1C)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  intergroup 
coordination  process. 


Documented  Procedures 

References 

Critical  dependencies  between  engineering  groups  are 
identified,  negotiated,  and  tracked  according  to  a 
documented  procedure.  (L3-89,  A4) 

This  procedure  typically  specifies  that; 

□  Each  critical  dependency  is  explicitly  defined,  including: 

□  the  item  to  be  provided, 

□  who  will  provide  it, 

□  when  it  will  be  provided,  and 

□  the  criteria  for  acceptance. 

□  Critical  dependencies  are  negotiated  between  the 
software  engineering  group  and  other  engineering 
groups  in  the  project  and  organization. 

□  Need  dates  and  availability  dates  of  critical  dependency 
items  are  tied  to  the  project  schedule  and  the  software 
schedule. 

□  The  agreement  for  each  critical  dependency  is 
documented,  reviewed,  and  approved  by  both  the 
receiving  group  and  the  group  responsible  for 
providing  the  critical  dependency  item. 

□  Critical  dependencies  are  tracked  on  a  regular  basis  and 
corrective  actions  are  taken  when  appropriate. 

□  Status  and  actual  or  projected  completion  are 
compared  to  the  plan  used  to  coordinate  intergroup 
commitments. 

□  Effects  of  late  and  early  completions  are  evaluated 
for  impacts  on  future  activities  and  milestones. 

□  Actual  and  potential  problems  are  reported  to  the 
appropriate  managers. 

_ 1 

Intergroup  issues  not  resolvable,  by  the  individual 
representatives  of  the  project  engineering  groups  are 
handled  according  to  a  documented  procedure.  (L3-90, 

A6) 
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Peer  Reviews  (PR)  Procedure 


Documented 

procedure 


The  table  below  lists  the  recommended  documented  procedure  for  the  peer  reviews 
process. 


Documented  Procedure 

References 

Peer  reviews  are  performed  according  to  a  documented 
procedure.  (L3-97,  A2) 

This  procedure  typically  specifies  that: 

□  Peer  reviews  are  planned  and  led  by  trained  peer  review 
leaders. 

□  Review  materials  are  distributed  to  the  reviewers  in 
advance  so  they  can  adequately  prepare  for  the  peer 
review. 

□  Reviewers  have  assigned  roles  in  peer  reviews. 

□  Readiness  and  completion  criteria  for  the  peer  reviews 
are  specified  and  enforced. 

□  Issues  in  satisfying  these  criteria  are  reported  to  the 
appropriate  managers. 

□  Checklists  are  used  to  identify  criteria  for  the  review  of 
the  software  work  products  in  a  consistent  manner. 

□  The  checklists  are  tailored  to  the  specific  type  of 
work  product  and  peer  review. 

□  The  checklists  are  reviewed  by  the  checklist 
developers'  peers  and  potential  users. 

□  Actions  identified  in  the  peer  reviews  are  tracked  until 
they  are  resolved. 

□  The  successful  completion  of  peer  reviews,  including  the 
rework  to  address  the  items  identified  in  the  peer  reviews, 
is  used  as  a  completion  criterion  for  the  associated  task. 
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Level  3  Summary 
Overview 


Section  purpose  The  puqjose  of  this  section  is  to  provide  checklists  that  provide  a  summary  of  the 
defined  level  (level  3).  This  section  contains  three  perspectives  of  a  CMM  level. 

•  Key  process  area  {KPA)  specific  information: 

KPA  purpose 

KPA  goals 

•  Operational  framework  information  (from  a  maturity  level  viewpoint): 

Policies 

Standards 

Process  descriptions 

Procedures 

Training 

Tools 

•  Other  key  process  information  (from  a  maturity  level  viewpoint): 

Reviews  and  audits 

Work  products  managed  and  controlled 
Measurements 


Section  This  section  contains  the  following  topics, 

overview 


Topic 

Page 

Level  3  -  KPA  Purposes 

L3-Summary-2 

Level  3  -  KPA  Goals 

L3-Summary-3 

Level  3  -  Policies 

L3-Summary-4 

Level  3  -  Standards 

L3-Summary-5 

Level  3  -  Process  Descriptions 

L3-Summary-6 

Level  3  -  Procedures 

L3-Summary-9 

Level  3  -  Training 

L3-Summary-1 1 

Level  3  -  Tools 

L3-Summary-13 

Level  3  -  Reviews  and  Audits 

L3-Summary-14 

Level  3  -  Work  Products  Managed  and  Controlled 

L3-Summary-25 

Level  3  -  Measurements 

L3-Summary-27 
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Level  3  -  KPA  Purposes 


Level  3  KPA 
purposes 


The  followiim  table  describes  the  purpose  of  each  key  process  area  in  the  CMM  at 
level  3. 


I 

V 

KPA 

Purpose  of  KPAs  at  Level  3 

OPF 

The  purpose  of  Organization  Process  Focus  is  to  establish  the 
organizational  responsibility  for  software  process  activities  that 
improve  the  organization's  overall  software  process  capability.  (L3  -1) 

OPD 

The  purpose  of  Organization  Process  Definition  is  to  develop  and 
maintain  a  usable  set  of  software  process  assets  that  improve  proc.;ss 
performance  across  the  projects  and  provide  a  basis  for  cumulative, 
long-term  benefits  to  the  organization.  (L3-1 1) 

TP 

The  purpose  of  the  Training  Program  key  process  area  is  to  develop  the 
skills  and  knowledge  of  individuals  so  they  can  perform  their  roles 
effectively  and  efficiently.  (L3-25) 

ISM 

The  purpose  of  Integrated  Software  Management  is  to  integrate  the 
software  engineering  and  management  activities  into  a  coherent, 
defined  software  process  that  is  tailored  from  the  organization's 
standard  software  process  and  related  process  assets,  which  are 
described  in  Organization  Process  Definition.  (L3-37) 

SPE 

The  purpose  of  Software  Product  Engineering  is  to  consistently 
perform  a  well-defined  engineering  process  that  integrates  all  the 
software  engineering  activities  to  produce  correct,  consistent  software 
products  effectively  and  efficiently.  (L3-59) 

IC 

The  purpose  of  Intergroup  Coordination  is  to  establish  a  means  for  the 
software  engineering  group  to  participate  actively  with  the  other 
engineering  groups  so  the  project  is  letter  able  to  satisfy  the  customer's 
needs  effectively  and  efficiently.  (L3-83) 

PR 

The  purpose  of  Peer  Reviews  is  to  remove  defects  from  the  software 
work  products  early  and  efficiently.  An  important  corollary  effect  is  to 
develop  a  better  understanding  of  the  software  work  products  and  of 
defects  that  might  be  prevented.  (L3-93) 
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Level  3  -  KPA  Goals 


Level  3  KPA 
goals 


The  following  table  lists  the  goals  that  are  described  in  the  CMM  for  each  key  process 
area  at  level  3. 


V 

KPA 

CMM  Goals  at  Level  3 

References 

OPF 

Software  process  development  and  improvement 
activities  are  coordinated  across  the  organization.  (L3- 
l.Gl) 

OPF 

The  strengths  and  weaknesses  of  the  software 
processes  used  are  identified  relative  to  the  process 
standard.  (L3-2,  G2) 

OPF 

Organization-level  process  development  and 
improvement  activities  are  planned.  (L3-2,  G3) 

OPD 

A  standard  software  process  for  the  organization  is 
developed  and  maintained.  (L3-12,  Gl) 

OPD 

Information  related  to  the  use  of  the  organization’s 
standard  software  process  by  the  software  projects  is 
collected,  reviewed,  and  made  available.  (L3-12,  G2) 

TP 

Training  activities  are  planned.  (L3-25,  Gl) 

TP 

Training  for  developing  the  skills  and  knowledge 
needed  to  perform  software  management  and  technical 
roles  is  provided.  (L3-25,  G2) 

TP 

Individuals  in  the  software  engineering  group  and 
software-related  groups  receive  the  training 
necessary  to  perform  their  roles.  (L3-26,  G3) 

ISM 

The  project's  defined  software  process  is  a  tailored 
version  of  the  organization’s  standard  software  process. 
(L3-38,G1) 

ISM 

The  project  is  planned  and  managed  according  to  the 
project's  defined  software  process.  (L3-38,  G2) 

SPE 

The  software  engineering  tasks  are  defined,  integrated, 
and  consistently  performed  to  produce  the  software. 
(L3-60,G1) 

SPE 

Software  work  products  are  kept  consistent  with  each 
other.  (L3-60,G2) 

IC 

The  customer's  requirements  are  agreed  to  by  all 
affected  groups.  (L3-84,  Gl) 

IC 

The  commitments  between  the  engineering  groups  are 
agreed  to  by  the  affected  groups.  (L3-84,  G2) 

IC 

The  engineering  groups  identify,  track,  and  resolve 
intergroup  issues.  (L3-84,  G3) 

PR 

Peer  reviews  are  planned.  (L3-93,  Gl) 

PR 

Defects  in  the  software  work  products  are  identified 
and  removed.  (L3-93,  G2) 
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Level  3  -  Policies 


Level  3  policies  The  following  table  lists  the  recommended  policies  in  the  CMM  at  level  3. 


KPA 

Description 

OPF 

Written  organizational  policy  for  coordinating  software 
process  development  and  improvement  activities 
across  the  organization.  (L3-2,  Cl) 

OPD 

Written  policy  for  developing  and  maintaining  a 
standard  software  process  and  related  process  assets. 
(L3-12,C1) 

TP 

Written  policy  for  meeting  the  organization’s  training 
needs.  (L3-26,  Cl) 

ISM 

Written  organizational  policy  requiring  that  the 
software  project  be  planned  and  managed  using  the 
organization's  standard  software  process  and  related 
process  assets.  (L3-38,  Cl) 

SPE 

Written  organizational  policy  for  performing  the 
software  engineering  activities.  (L3-60,  Cl) 

IC 

Written  organizational  policy  for  establishing 
interdisciplinary  engineering  teams.  (L3-84,  Cl) 

PR 

Written  organizational  policy  for  performing  peer 
reviews.  (L3-94,  Cl) 

References 


L3-Summary-4 


CMU/SEI-94-HB-1 


Level  3  -  Standards 


Level  3 
standards 


Reference 


The  CMM  recommends  the  contents  of  the  following  work  products  at  level  3: 


T 

KPA 

Standards  at  Level  3 

References 

OFF 

Action  plan.  (L3-6,  Al) 

OFF 

Software  development  and  improvement  plan.  (L3-7, 
A2) 

OFD 

Organization’s  standard  software  process.  (L3- 17,  A2) 

OFD 

Software  process  element.  (L3-17,  A2,  2) 

OFD 

Tailoring  guidelines  and  criteria  (for  projects’  tailoring 
of  the  organization’s  standard  software  process).  (L3- 
19,A4,1) 

TP 

Software  project’s  training  plan.  (L3-29,  Al) 

TP 

Organization’s  training  plan.  (L3-32,  A3) 

TP 

Organizational  standards  for  training  courses.  (L3-33, 
A4) 

ISM 

Project’s  defined  software  process.  (L3-44,  A4) 

SPE 

Software  design  documentation.  (L3-7 1 ,  A3,  8. 1 ) 

SPE 

Test  plan.  (L3-75,  A7, 2) 

IC 

Documented  plan  for  intergroup  commitments.  (L3- 
88,  A3) 

PR 

Plans  for  peer  reviews.  (L3-97,  Al) 

Refer  to  the  Level  3  Standards  Checklists  for  additional  infoimation  regarding  the 
content  of  each  standard. 
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Level  3  -  Process  Descriptions 


OPF  process 
description 


OPD  process 
description 


Organization  Process  Focus  involves  developing  and  maintaining  an  understanding  of 
the  organization's  and  projects'  software  processes  and  coordinating  the  activities  to 
assess,  develop,  maintain,  and  improve  these  processes. 

The  organization  provides  the  long-term  commitments  and  resources  to  coordinate  the 
development  and  maintenance  of  the  software  processes  across  current  and  future 
software  projects  via  a  group  such  as  a  software  engineering  process  group.  This 
group  is  responsible  for  the  organization's  software  process  activities.  It  is  specifically 
responsible  for  the  development  and  maintenance  of  the  organization's  standard 
software  process  and  related  process  assets  (as  described  in  the  Organization  Process 
Definition  key  process  area),  and  it  coordinates  the  process  activities  with  the  software 
projects.  (L3-1) 


Organization  Process  Definition  involves  developing  and  maintaining  the 
organization's  standard  software  process,  along  with  related  process  assets,  such  as 
descriptions  of  software  life  cycles,  process  tailoring  guidelines  and  criteria,  the 
organization's  software  process  database,  and  a  library  of  software  process-related 
documentation. 


These  assets  may  be  collected  in  many  ways,  depending  on  the  organization's 
implementation  of  Organization  ft'ocess  Definition.  For  example,  the  descriptions  of 
the  software  life  cycles  may  be  an  integral  part  of  the  organization's  standard  software 
process  or  parts  of  the  library  of  software  process-related  documentation  may  be 
stored  in  the  organization's  software  process  database. 


The  organization's  software  process  assets  are  available  for  use  in  developing, 
implementing,  and  maintaining  the  projects’  defined  software  processes.  (The 
practices  related  to  the  development  and  maintenance  of  the  project's  defined  software 
process  are  described  in  the  Integrated  Software  Management  key  process  area.)  (L3- 


Cnnlinued  on  next  page 
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Level  3  -  Process  Descriptions,  continued 


TP  process 
description 


ISM  process 
description 


Training  Program  involves  first  identifying  the  training  needed  by  the  organization, 
projects,  and  individuals,  then  developing  or  procuring  training  to  address  the 
identified  needs. 

Each  software  project  evaluates  its  current  and  future  skill  needs  and  determines  how 
these  skills  will  be  obtained.  Some  skills  are  effectively  and  efficiently  imparted 
through  informal  vehicles  (e.g.,  on-the-job  training  and  informal  mentoring),  whereas 
other  skills  need  more  formal  training  vehicles  (e.g.,  classroom  training  and  guided 
self-study)  to  be  effectively  and  efficiently  imparted.  The  appropriate  vehicles  are 
selected  and  used. 

This  key  process  area  covers  the  practices  for  the  group  performing  the  training 
function.  The  practices  identifying  the  specific  training  topics  (i.e.,  knowledge  or  skill 
needed)  are  contained  in  the  Ability  to  Perform  common  feature  of  the  individual  key 
process  areas.  (L3-25) 


Integrated  Software  Management  involves  developing  the  project's  defined  software 
process  and  managing  the  software  project  using  this  defined  software  process.  The 
project's  defined  software  process  is  tailored  from  the  organization's  standard  software 
process  to  address  the  specific  characteristics  of  the  project. 

The  software  development  plan  is  based  on  the  project's  defined  software  process  and 
describes  how  the  activities  of  the  project's  defined  software  process  will  be 
implemented  and  managed.  The  management  of  the  software  project's  size,  effort, 
cost,  schedule,  staffing,  and  other  resources  is  tied  to  the  tasks  of  the  project's  defined 
software  process. 

Since  the  projects'  defined  software  processes  are  all  tailored  from  the  organization's 
standard  software  process,  the  software  projects  can  share  process  data  and  lessons 
learned. 

The  basic  practices  for  estimating,  planning,  and  tracking  a  software  project  are 
described  in  the  Software  Project  Planning  and  Software  Project  Tracking  and 
Oversight  key  process  areas.  They  focus  on  recognizing  problems  when  they  occur 
and  adjusting  the  plans  and/or  performance  to  address  the  problems.  The  practices  of 
this  key  process  area  build  on,  and  are  in  addition  to,  the  practices  of  those  two  key 
process  areas.  The  emphasis  of  Integrated  Software  Management  shifts  to  anticipating 
problems  and  acting  to  prevent  or  minimize  the  effects  of  these  problems.  (L3-37) 


Continued  on  next  page 


CMU/SEI-94-HB-1 


L3-Summary-7 


Level  3  -  Process  Descriptions,  continued 


SPE  process 
description 


IC  process 
description 


PR  process 
description 


Software  Product  Engineering  involves  performing  the  engineering  tasks  to  build  and 
maintain  the  software  using  the  project's  defined  software  process  (which  is  described 
in  the  Integrated  Software  Management  key  process  area)  and  appropriate  methods 
and  tools. 

The  software  engineering  tasks  include  analyzing  the  system  requirements  allocated  to 
software  (these  system  requirements  are  described  in  the  Requirements  Management 
key  process  area),  developing  the  software  requirements,  developing  the  software 
architecture,  designing  the  software,  implementing  the  software  in  the  code, 
integrating  the  software  components,  and  testing  the  software  to  verify  that  it  satisfies 
the  specified  requirements  (i.e.,  the  system  requirements  allocated  to  software  and  the 
software  requirements). 

Documentation  needed  to  perform  the  software  engineering  tasks  (e.g.,  software 
requirements  document,  software  design  document,  test  plan,  and  test  procedures)  is 
developed  and  reviewed  to  ensure  that  each  task  addresses  the  results  of  predecessor 
tasks  and  the  results  produced  are  appropriate  for  the  subsequent  tasks  (including  the 
tasks  of  operating  and  maintaining  the  software).  When  changes  are  approved, 
affected  software  work  products,  plans,  commitments,  processes,  and  activities  are 
revised  to  reflect  the  approved  changes.  (L3-59) 


Intergroup  Coordination  involves  the  software  engineering  group's  participation  with 
other  project  engineering  groups  to  address  system-level  requirements,  objectives,  and 
issues.  Representatives  of  the  project's  engineering  groups  participate  in  establishing 
the  system-level  requireinents,  objectives,  and  plans  by  working  with  the  customer  and 
end  users,  as  appropriate.  These  requirements,  objectives,  and  plans  become  the  basis 
for  all  engineering  activities. 

The  technical  working  interfaces  and  interactions  between  groups  are  planned  and 
managed  to  ensure  the  quality  and  integrity  of  the  entire  system.  Technical  reviews 
and  interchanges  are  regularly  conducted  with  representatives  of  the  project’s 
engineering  groups  to  ensure  that  all  engineering  groups  are  aware  of  the  status  and 
plans  of  all  the  groups,  and  that  system  and  intergroup  issues  receive  appropriate 
attention. 

The  software-specific  practices  related  to  these  engineering  tasks  are  described  in  the 
Requirements  Management  and  Software  Product  Engineering  key  process  areas.  (L3- 
83) 


Peer  Reviews  involve  a  methodical  examination  of  software  work  products  by  the 
producers'  peers  to  identify  defects  and  areas  where  changes  are  needed.  The  specific 
products  that  will  undergo  a  peer  review  are  identified  in  the  project's  defined  software 
process  and  scheduled  as  part  of  the  software  project  planning  activities,  as  described 
in  Integrated  Software  Management. 

This  key  process  area  covers  the  practices  for  performing  peer  reviews.  The  practices 
identifying  the  specific  software  work  products  that  undergo  peer  review  are  contained 
in  the  key  process  areas  that  describe  the  development  and  maintenance  of  each 
software  work  product.  (L3-93) 
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Level  3  -  Procedures 


Level  3 
procedures 


The  table  below  lists  the  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  3.  Refer  to  the  Level  3  Procedure 
Checklists  for  additional  information  regarding  the  content  of  each  documented 
procedure. 


V 

KPA 

Documented  Procedures 

References 

OPF 

There  are  no  activities  that  are  recoinmended  to  be 
performed  according  to  a  documented  procedure  in  the 
organizational  process  focus  process. 

OPD 

The  organization’s  standard  software  process  is 
developed  and  maintained  according  to  a  documented 
procedure.  (L3-15,  Al) 

TP 

The  organization's  training  plan  is  developed  and 
revised  according  to  a  documented  procedure.  (L3-30, 
A2) 

ISM 

The  project's  defined  software  process  is  developed  by 
tailoring  the  organization’s  standard  software  process 
according  to  a  documented  procedure.  (L3-41 ,  Al ) 

ISM 

Each  project's  defined  software  process  is  revised 
according  to  a  documented  procedure.  (L3-43,  A2) 

ISM 

The  project's  software  development  plan,  which 
describes  the  use  of  the  project’s  defined  software 
process,  is  developed  and  revised  according  to  a 
documented  procedure.  (L3-44,  A3) 

ISM 

The  size  of  the  software  work  products  (or  size  of 
changes  to  the  software  work  products)  is  managed 
according  to  a  documented  procedure.  (L3-47,  A6) 

ISM 

The  project's  softy 'i.  >-6  effort  and  costs  are  managed 
according  to  a  documented  procedure.  (L3-48,  A7) 

ISM 

The  project's  critical  computer  resources  are  managed 
according  to  a  documented  procedure.  (L3-50,  A8) 

ISM 

The  critical  dependencies  and  critical  paths  of  the 
project's  software  schedule  are  managed  according  to  a 
documented  procedure.  (L3'51,  A9) 

ISM 

The  project's  software  risks  are  identified,  assessed, 
documented,  and  managed  according  to  a  documented 
procedure.  (L3-52,  AlO) 

SPE 

There  are  no  activities  that  are  recommended  to  be 
performed  according  to  a  documented  procedure  in  the 
software  product  engineering  process. 

Continued  on  next  page 
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Level  3  -  Procedures,  Continued 


Level  3 

procedures, 

continued 


V 

KPA 

Documented  Procedures 

References 

IC 

Critical  dependencies  between  engineering  groups  are 
identified,  negotiated,  and  tracked  according  to  a 
documented  procedure.  (L3-89,  A4) 

IC 

Intergroup  issues  not  resolvable  by  the  individual 
representatives  of  the  project  engineering  groups 
are  handled  according  to  a  documented  procedure. 
(L3-90,  A6) 

PR 

Peer  reviews  are  performed  according  to  a  documented 
procedure.  (L3-97,  A2) 

The  table  below  lists  the  activities  that  are  recommended  to  be  performed  according  to 
a  documented  procedure  in  the  CMM  at  level  3,  continued  from  the  previous  page. 
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Level  3  -  Training 


Level  3  training  The  table  below  lists  the  training  recommended  in  the  CMM  at  level  3. 


KPA 

Training 

OPF 

Members  of  the  group  responsible  for  the 
organization’s  software  process  activities  receive 
required  training  to  perform  these  activities.  (L3-5, 

Ab3) 

OPF 

Members  of  the  software  engineering  group  and 
other  software-related  groups  receive  orientation  on 
the  organization’s  software  process  activities  and  their 
roles  in  those  activities.  (L3-6,  Ab4) 

OPF 

Training  for  the  organization’s  and  projects’  software 
processes  is  coordinated  across  the  organization.  (L3- 
8,  A6) 

OPD 

The  individuals  who  develop  and  maintain  the 
organization's  standard  software  process  and 
related  process  assets  receive  required  training  to 
perform  these  activities.  (L3-14,  Ab2) 

TP 

Training  is  provided  to  build  the  skill  base  of  the 
organization,  to  fill  the  specific  needs  of  the  projects, 
and  to  develop  the  skills  of  individuals.  (L3-26,  Cl,  3) 

TP 

Software  managers  receive  orientation  on  the  training 
program.  (L3-29,  Ab4) 

ISM 

The  individuals  responsible  for  developing  the 
project's  defined  software  process  receive  required 
training  in  how  to  tailor  the  organization’s  standard 
software  process  and  use  the  related  process  assets. 
(L3-39,  Ab2) 

ISM 

The  software  managers  receive  required  training  in 
managing  the  technical,  administrative,  and  personnel 
aspects  of  the  software  project  based  on  the  project’s 
defined  software  process.  (L3-40,  Ab3) 

SPE 

Members  of  the  software  engineering  technical  staff 
receive  required  training  to  perform  their  technical 
assignments.  (L3-63,  Ab2) 

SPE 

Members  of  the  software  engineering  technical  staff 
receive  orientation  in  related  software  engineering 
disciplines.  (L3-64,  Ab3) 

SPE 

The  project  manager  and  all  software  managers 
receive  orientation  in  the  technical  aspects  of  the 
software  project.  (L3-64,  Ab4) 

IC 

All  managers  in  the  organization  receive  required 
training  in  teamwork.  (L3-85,  Ab3) 

References 


Level  3  -  Training,  continued 


Level  3 

training, 

continued 


The  table  below  lists  the  training  recommended  in  the  CMM  at  level  3,  continued  from 
the  previous  page. 


V 

KPA 

Training 

References 

IC 

All  task  leaders  in  each  engineering  group  receive 
orientation  in  the  processes,  methods,  and  standards 
used  by  the  other  engineering  groups.  (L3-86,  Ab4) 

IC 

The  members  of  the  engineering  groups  receive 
orientation  in  working  as  a  team.  (L3-86,  Ab5) 

PR 

Peer  review  leaders  receive  required  training  in  how 
to  lead  peer  reviews.  (L3-95,  Ab2) 

PR 

Reviewers  who  participate  in  peer  reviews  receive 
required  training  in  the  objectives,  principles,  and 
methods  of  peer  reviews.  (L3-96,  Ab3) 
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Level  3  tools 


The  table  below  lists  the  tools  recommended  in  the  CMM  for  level  3. 


KPA 

Tools 

References 

OFF 

Tools  to  support  the  organization’s  software  process 
activities.  (L3-5,  Ab2,  2) 

OPD 

Tools  to  support  process  development  and 
maintenance.  (L3-14,  Abl,  2) 

OPD 

State-of-the-practice  softwaie  engineering  tools.  (L3- 
15,  Al,3) 

OPD 

Organization’s  software  process  database.  (L3-20,  A5) 

TP 

Tools  to  support  the  training  program  activities.  (L3- 
28,  Ab2,  2) 

ISM 

Organization's  software  process  database.  (L3-39,  Cl, 
4) 

SPE 

Tools  to  build  and  maintain  the  software  products. 
(L3-60,Cl,2) 

SPE 

Tools  to  support  the  software  engineering  tasks.  (L3- 
61,  Abl,  2) 

SPE 

Software  engineering  tools.  (L3-65,  Al) 

SPE 

Tools  to  develop  the  documentation.  (L3-76,  A8, 1) 

IC 

Support  tools  used  by  the  different  engineering  groups. 
(L3-85,  Ab2) 

PR 

There  are  no  tools  specified  in  the  peer  reviews 
process. 
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Level  3  reviews 
and  audits 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3. 


~T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

OFF 

The  plan  for  organizational  software 
process  development  and 
improvement  activities  undergoes  peer 
review  when  initially  released  and 
whenever  major  revisions  are  made. 
(L3-7,  A2,  5) 

Not  specified 
in  the  CMM 

OFF 

The  plan  for  organizational  software 
process  development  and 
improvement  activities  is  reviewed 
and  agreed  to  by  the  organization’s 
software  managers  and  senior 
managers.  (L3-7,  A2, 6) 

Software 

managers 

Senior 

managers 

OFF 

The  activities  for  software  process 
development  and  improvement  are 
reviewed  with  senior  management  on 
a  periodic  basis.  (L3-10,  VI) 

Senior 

management 

OFF 

Frogress  and  status  of  the  activities  to 
develop  and  improve  the  software 
process  are  reviewed  against  the  plan. 
(L3-10,V1,1) 

Not  specified 
in  the  CMM 

OFD 

Changes  proposed  for  the 
organization's  standard  software 
process  are  documented,  reviewed, 
and  approved  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g., 
software  engineering  process  group) 
before  they  are  incoiporated.  (L3-16, 
Al,6) 

Group 
responsible 
for  the 
organiza¬ 
tion's 
software 
process 
activities 

OFD 

The  description  of  the  organization's 
standard  software  process  undergoes 
peer  review  when  initially  developed 
and  whenever  significant  changes  or 
additions  are  made.  (L3-16,  Al,8) 

Not  specified 
in  the  CMM 

OFD 

Changes  proposed  for  the  descriptions 
of  software  life  cycles  are 
documented,  reviewed,  and  approved 
by  the  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  before  they  are 
incorporated.  (L3-I8,  A3,  2) 

Group 
responsible 
for  the 
organiza¬ 
tion's 
software 
process 
activities 

Continued  on  next  page 
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Level  3  -  Reviews  and  Audits,  Continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


KPA 

Review  or  Audit 

Review 

Participants 

References 

OPD 

The  descriptions  of  the  software  life 
cycles  undergo  peer  review  when 
initially  documented  and  whenever 
significant  changes  or  additions  are 
made.  (L3-19,  A3,  3) 

Not  specified 
in  the  CMM 

OPD 

Changes  proposed  for  the  tailoring 
guidelines  and  criteria  are 
documented,  reviewed,  and  approved 
by  the  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  before  they  are 
incorporated.  (L3-20,  A4, 2) 

Group 
responsible 
for  the 
organiza¬ 
tion's 
software 
process 
activities 

OPD 

The  data  entered  into  the 
(organization's  software  process) 
database  are  reviewed  to  ensure  the 
integrity  of  the  database  contents. 
(L3-21,A5,2) 

Not  specifted 
in  the  CMM 

OPD 

Candidate  (software  process-related) 
documentation  items  are  reviewed  and 
appropriate  items  that  may  be  useful  in 
the  future  are  included  in  the  library. 
(L3-21,A6, 1) 

Not  specified 
in  the  CMM 

OPD 

Revisions  made  to  (software  process- 
related)  documentation  items  currently 
in  the  library  are  reviewed,  and  the 
library  contents  are  updated  as 
appropriate.  (L3-22,  A6,  3) 

Not  specifled 
in  the  CMM 

OPD 

The  use  of  each  (software  process- 
related)  documentation  item  is 
reviewed  periodically,  and  the  results 
are  used  to  maintain  the  library 
contents.  (L3-22,  A6, 5) 

Not  specified 
in  the  CMM 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L3-Summary-15 


Level  3  -  Reviews  and  Audits,  continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


V 

KPA 

Review  or  Audit 

Review 

Participants 

References 

OPD 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
organization’s  activities  and  work 
products  for  developing  and 
maintaining  the  organization's 
standard  software  process  and  related 
process  assets  and  reports  the  results. 
(L3-23,  VI) 

Software 

quality 

assurance 

group 

TP 

The  organization's  training  plan  is 
reviewed  by  the  affected  individuals 
when  it  is  initially  released  and 
whenever  major  revisions  are  made. 
(L3-31,  A2, 4) 

Affected 

individuals 

TP 

The  materials  for  the  training  course 
are  reviewed.  (L3-33,  A4,  2) 

Not  specified 
in  the  CMM 

TP 

The  training  program  activities  are 
reviewed  with  senior  management  on 
a  periodic  basis.  {L3-35,  VI) 

Senior 

management 

TP 

The  training  program  is  independently 
evaluated  on  a  periodic  basis  for 
consistency  with,  and  relevance  to,  the 
organization's  needs.  (L3-36,  V2) 

Not  specifled 
in  the  CMM 

TP 

The  training  program  activities  and 
work  products  are  reviewed  and/or 
audited  and  the  results  are  reported. 
(L3-36,  V3) 

Not  specified 
in  the  CMM 

ISM 

Tailoring  of  the  organization’s 
standard  software  process  for  the 
project  is  reviewed  by  the  group 
responsible  for  coordinating  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  and  approved  by 
senior  management.  (L3-42,  Al,3) 

Group 
responsible 
for  the 
organiza¬ 
tion's 
software 
process 
activities 

Senior 

management 

ISM 

Waivers  for  deviations  from  the 
organization's  standard  software 
process  are  documented  and  are 
reviewed  and  approved  by  senior 
management.  (L3-42,  Al,  3.1) 

Senior 

management 
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Level  3  -  Reviews  and  Audits,  continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


V 

KPA 

Review  or  Audit 

Review 

Participants 

References 

ISM 

Waivers  for  deviations  from 
contractual  software  process 
requirements  are  documented  and  are 
reviewed  and  approved  by  senior 
management  and  the  software 
project's  customer,  as  appropriate. 
(L3-42,  Al,  4) 

Senior 

management 

Customer 

ISM 

Changes  derived  from  the  following 
are  documented  and  systematically 
reviewed;  (L3-43,  A2, 1) 

□  lessons  learned  from  monitoring 
the  software  activities  of  the 
organization's  projects, 

□  changes  proposed  by  the  software 
project,  and 

□  process  and  work  product 
measurement  data. 

Not  specified 
in  the  CMM 

ISM 

Changes  to  the  project's  defined 
software  process  are  reviewed  and 
approved  before  they  are  incorporated. 
(L3-43,  A2,  2) 

Not  specifted 
in  the  CMM 

ISM 

Technical  and  management  lessons 
learned  from  monitoring  the  activities 
of  other  projects  in  the  organization 
are  systematically  reviewed  and  used 
to  estimate,  plan,  track,  and  replan  the 
software  project.  (L3-45,  A4, 6) 

Not  specified 
in  the  CMM 

ISM 

A  group  that  is  independent  of  the 
software  engineering  group  reviews 
the  procedures  for  estimating  the  size 
of  the  software  work  products,  and 
provides  guidance  in  using  historical 
data  from  the  organization's  software 
process  database  to  establish  credible 
estimates.  (L3-47,  A6, 1) 

Group  that  is 

independent 

of  the 

software 

engineering 

group 

ISM 

When  the  validity  of  a  size  estimate  is 
questioned,  a  team  of  peers  and 
experts  reviews  the  estimate.  (L3-48, 
A6, 1.2) 

Team  of 
peers  and 
experts 

Continued  on  next  page 
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Level  3  -  Reviews  and  Audits,  Continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


V 

KPA 

Review  or  Audit 

Review 

Participants 

References 

ISM 

When  the  software  effort  and  cost 
status  is  reviewed  and  the  estimates 
are  revised,  actual  expenditures  over 
time  and  against  work  completed  are 
compared  to  the  software  development 
plan  and  used  to  refine  the  effort  and 
cost  estimates  for  remaining  work. 
(L3-49,A7.4) 

Not  specified 
in  the  CMM 

ISM 

The  initial  release  and  major  revisions 
to  the  software  risk  management  plan 
undergo  peer  review.  (L3-54,  A 10, 4) 

Not  specified 
in  the  CMM 

ISM 

Risk  priorities  and  software  risk 
management  plans  are  reviewed  and 
revised  at  these  reassessment  points  (at 
selected  project  milestones,  at 
designated  risk  checkpoints,  and 
during  the  planning  of  significant 
changes  that  affect  the  software 
project).  (L3'55,  AlO,  6.1) 

Not  specified 
in  the  CMM 

ISM 

Reviews  of  the  software  project  are 
periodically  performed  to  determine 
the  actions  needed  to  bring  the 
software  project's  performance  and 
results  in  line  with  the  current  and 
projected  needs  of  the  business, 
customer,  and  end  users,  as 
appropriate.  (L3-55, All) 

Not  specified 
in  the  CMM 

ISM 

The  activities  for  managing  the 
software  project  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L3-56,  VI) 

Senior 

management 

ISM 

The  activities  for  managing  the 
software  project  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  basis.  (L3-57,  V2) 

Project 

manager 

ISM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
managing  the  software  project  and 
reports  the  results.  (L3-57,  V3) 

Software 

quality 

assurance 

group 
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Level  3  •  Reviews  and  Audits,  continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


V 

KPA 

Review  or  Audit 

Re\'iew 

Participants 

References 

SPE 

The  individuals  involved  in 
developing  the  software 
requirements  review  the  allocated 
requirements  to  ensure  that  issues 
affecting  the  software  requirements 
analysis  are  identified  and  resolved. 
(L3-66,  A2, 1) 

Individuals 
involved  in 
developing 
the  software 
requirements 

SPE 

Problems  with  the  software 
requirements  are  identified  and 
reviewed  with  the  group  responsible 
for  the  system  requirements; 
appropriate  changes  are  made  to  the 
allocated  requirements  and  to  the 
software  requirements.  (L3-67,  A2, 
4.1) 

Group 
responsible 
for  tlie 
system 
requirements 

SPE 

The  software  requirements  document 
undergoes  peer  review  before  it  is 
considered  complete.  (L3-68,  A2,  8) 

Not  specified 
in  the  CMM 

SPE 

The  software  requirements  document 
is  reviewed  and  approved.  (L3-68, 

A2,  9) 

Not  specified 
in  the  CMM 

SPE 

The  software  requirements  document 
is  reviewed  with  the  customer  and 
end  users,  as  appropriate.  (L3-68,  A2, 
10) 

Customer 

End  users 

SPE 

Design  criteria  are  developed  and 
reviewed.  (L3-69,  A3, 1) 

Not  specified 
in  the  CMM 

SPE 

The  individuals  involved  in  the 
software  design  review  the  software 
requirements  to  ensure  that  issues 
affecting  the  software  design  are 
identified  and  resolved.  (L3-69,  A3, 

2) 

Individuals 
involved  in 
the  software 
design 

SPE 

The  software  architecture  is  reviewed 
to  ensure  that  architecture  issues 
affecting  the  software  detailed  design 
are  identified  and  resolved.  (L3-70, 
A3,  6) 

Not  specified 
in  the  CMM 
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Level  3  -  Reviews  and  Audits,  Continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


KP.4 

Review  or  Audit 

Review 

Participants 

References 

SPE 

Tlie  software  design  document 
u.idergoes  peer  review  before  the 
design  is  considered  complete.  (L3- 
71,  A3, 9) 

Not  specified 
in  the  CMM 

SPE 

The  individuals  involved  in  coding 
review  the  software  requirements  and 
software  design  to  ensure  that  issues 
affecting  the  coding  are  identified  and 
resolved.  (L3-71,  A4,  1) 

Individuals 
involved  in 
coding 

SPE 

Each  code  unit  undergoes  peer  review 
and  is  unit  tested  before  the  unit  is 
considered  complete.  (L3-72,  A4, 4) 

Not  specified 
in  the  CMM 

SPE 

Testing  criteria  are  developed  and 
reviewed  with  the  customer  and  the 
end  users,  as  appropriate.  (L3-72,  A5, 
1) 

Customer 

End  users 

SPE 

The  test  plan,  test  procedures,  and  test 
cases  undergo  peer  review  before  they 
are  considered  ready  for  use.  (L3-74, 
A5,  6) 

Not  specified 
in  the  CMM 

SPE 

The  integration  test  cases  and  test 
procedures  are  reviewed  with  the 
individuals  responsible  for  the 
software  requirements,  software 
design,  and  system  and  acceptance 
testing.  (L3-75,  A6, 2) 

Individuals 
responsible 
for  the 
software 
require¬ 
ments, 
software 
design,  and 
system  and 
acceptance 
testing 

SPE 

System  and  acceptance  testing  are 
documented  in  a  test  plan,  which  is 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as 
appropriate.  (L3-75,  A7,  2) 

Customer 

End  users 
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Level  3  -  Reviews  and  Audits,  Continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


V 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SPE 

The  test  cases  are  documented  and  are 
reviewed  with,  and  approved  by,  the 
customer  and  end  users,  as 
appropriate,  before  the  testing  begins. 
(L3-76,  A7, 4) 

Customer 

End  users 

SPE 

Preliminary  versions  of  the 
documentation  (that  will  be  used  to 
operate  and  maintain  the  software)  are 
developed  and  made  available  early  in 
the  software  life  cycle  for  the 
customer,  end  users,  and  software 
maintainers,  as  appropriate,  to  review 
and  provide  feedback.  (L3-77,  A8, 3) 

Customer 

End  users 

Software 

maintainers 

SPE 

The  documentation  (that  will  be  used 
to  operate  and  maintain  the  software) 
undergoes  peer  review.  (L3-77,  A8,  5) 

Not  specified 
in  the  CMM 

SPE 

The  final  documentation  (that  will  be 
used  to  operate  and  maintain  the 
software)  is  reviewed  and  approved  by 
the  customer,  end  users,  and 
software  maintainers,  as  appropriate. 
(L3-77,  A8, 7) 

Customer 

End  users 

Software 

maintainers 

SPE 

The  activities  for  software  product 
engineering  are  reviewed  with  senior 
management  on  a  periodic  basis. 
(L3-80,V1) 

Senior 

management 

SPE 

The  activities  for  software  product 
engineering  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  basis.  (L3-80,  V2) 

Project 

manager 

SPE 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
software  product  engineering  and 
reports  the  results.  (L3-8I,V3) 

Software 

quality 

assurance 

group 

IC 

The  system  requirements  and  project- 
level  objectives  for  the  project  are 
defined  and  reviewed  by  all  affected 
groups.  (L3-84,C1,  1) 

Affected 

groups 

J _ 
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Level  3  -  Reviews  and  Audits,  Continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


V 

KPA 

Review  or  Audit 

Review 

Participants 

References 

IC 

Representatives  of  the  project's 
software  engineering  group  and 
representatives  of  the  other 
engineering  groups  provide  the 
technical  review  and  approval  of  the 
system  requirements  and  system 
design.  (L3-87,  A2, 1.1) 

Representa¬ 
tives  of  the 
project's 
software 
engineering 
group 

Representa¬ 
tives  of  the 
other 

engineering 

groups 

IC 

Representatives  of  the  project's 
software  engineering  group  and 
representatives  of  the  other 
engineering  groups  provide  the 
project-level  technical  review  and 
analysis  needed  to  manage  and  control 
changes  to  the  system  requirements 
and  project-level  objectives 
throughout  the  project's  life  cycle. 
(L3-87,  A2, 1.2) 

Representa¬ 
tives  of  the 
project's 
software 
engineering 
group 

Representa¬ 
tives  of  the 
other 

engineering 

groups 

IC 

Representatives  of  the  project's 
software  engineering  group  and 
representatives  of  the  other 
engineering  groups  track  and  review 
the  design  and  development  activities 
for  hardware,  software,  and  other 
system  components.  (L3-88,  A2, 1.3) 

Representa¬ 
tives  of  the 
project's 
software 
engineering 
group 

Representa¬ 
tives  of  the 
other 

engineering 

groups 

IC 

The  documented  plan  used  to 
communicate  intergroup  commitments 
and  to  coordinate  and  track  the  work 
performed  is  reviewed  and  agreed  to 
by  all  engineering  groups  and  the 
project  manager.  (L3-89,  A3, 6) 

Engineering 

groups 

Project 

manager 
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Level  3  -  Reviews  and  Audits,  Continued 


Level  3  reviews 
and  audits, 
continued 


ITie  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


KPA 

Review  or  Audit 

Review 

Participants 

References 

IC 

The  agreement  for  each  critical 
dependency  is  documented,  reviewed, 
and  approved  by  both  the  receiving 
group  and  the  group  responsible  for 
providing  the  critical  dependency 
item.  (L3-89,A4,4) 

Receiving 
group  (of  the 
critical 
dependency 
item) 

Group 
responsible 
for  providing 
the  critical 
dependency 
item 

IC 

Work  products  produced  as  input  to 
other  engineering  groups  are  reviewed 
by  representatives  of  the  receiving 
groups  to  ensure  that  the  work 
products  meet  their  needs,  (L3-90, 

A5) 

Representa¬ 
tives  of  the 
receiving 
groups 

IC 

Representatives  of  the  project 
engineering  groups  conduct  periodic 
technical  reviews  and  interchanges. 
(L3-90,  A7) 

Representa¬ 
tives  of  the 
project 
engineering 
groups 

IC 

The  activities  for  intergroup 
coordination  are  reviewed  with  senior 
management  on  a  periodic  basis. 
(L3-91,V1) 

Senior 

management 

IC 

The  activities  for  intergroup 
coordination  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  basis.  (L3-92,  V2) 

Project 

manager 

IC 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
intergroup  coordination  and  reports  the 
results.  (L3-92,V3) 

Software 

quality 

assurance 

group 
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Level  3  -  Reviews  and  Audits,  Continued 


Level  3  reviews 
and  audits, 
continued 


The  table  below  lists  the  reconimended  reviews  and  audits  in  the  CMM  at  level  3, 
continued  from  the  previous  page. 


KPA 

Review  or  Audit 

Review 

Participants 

References 

PR 

The  checklists  are  reviewed  by  the 
checklist  developers’  peers  and 
potential  users.  (L3-98,  A2, 5.2) 

Checklist 

developers' 

peers 

Checklist 

potential 

users 

PR 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for  peer 
reviews  and  reports  the  results.  (L3- 
100,  VI) 

Software 

quality 

assurance 

group 
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Level  3  -  Work  Products  Managed  and  Controlled 


Level  3  work 
products 
managed  and 
controlled 


The  table  belcw  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  in  the  CMM  at  level  3. 


V 

KPA 

Work  Products  Managed  and  Controlled 

References 

OPF 

There  are  no  work  products  recommended  to  be 
managed  and  controlled  in  the  organizational  process 
focus  process. 

OPD 

Description  of  the  organization’s  standard  software 
process.*  (L3-17,  Al,9) 

OPD 

Descriptions  of  the  software  life  cycles.  (L3-19,  A3, 4) 

OPD 

Tailoring  guidelines  and  criteria  (for  the  project’s 
tailoring  of  the  organization’s  standard  software 
process.  (L3-20,  A4,  3) 

OPD 

Organization's  software  process  database.  (L3-21,  A'', 
3) 

OPD 

Libraiy  of  software  process-related  documentation. 
(L3-21,A6, 6) 

TP 

The  organization’s  training  plan.  (L3-31,  A2,  5) 

TP 

The  materials  for  the  training  courses.  (L3-34,  A4, 3) 

ISM 

Description  of  the  project's  defined  software  process. 
(L3-42,A1,5) 

ISM 

Software  risk  management  plan.  (L3-54,  AlO,  5) 

SPE 

Tools  used  to  develop  and  maintain  the  software 
products.*  (L3-66,  Al,4) 

SPE 

Software  requirements  document.*  (L3-69,  A2, 11) 

SPE 

Software  design  document.*  (L3-71,  A3,  10) 

SPE 

Code.*  (L3-72,A4,5) 

SPE 

Test  plans,  test  procedures,  and  test  cases.  (L3-74,  A5, 
7) 

SPE 

Test  results.  (L3-76,  A7,  8) 

SPE 

Documentation  (that  will  be  used  to  operate  and 
maintain  the  software).  (L3-77,  A8, 6) 

SPE 

Documentation  tracing  the  allocated  requirements 
through  the  software  requirements,  design,  code,  and 
test  cases.  (L3-78,  AlO,  3) 

‘Indicates  that  the  CMM  recommends  that  this  item  must  be  placed  under 
configuration  management 
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Level  3  >  Work  Products  Managed  and  Controlled,  continued 


Level  3  work 
products 
managed  and 
controlled, 
continued 


The  table  below  li;.ts  the  work  products  that  are  recommended  to  be  managed  and 
controlled  in  the  CMM  at  level  3,  continued  from  the  previous  page. 


KPA 

Work  Products  Managed  and  Controlled 

References 

IC 

There  are  no  work  products  recommended  to  be 
managed  and  controlled  in  the  intergroup  coordination 
process. 

PR 

There  are  no  work  products  recommended  to  be 
managed  and  controlled  in  the  peer  reviews  process. 
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Level  3 

measurements 


The  table  below  describes  the  recommended  measurements  in  the  CMM  at  level  3. 


KPA 

Description 

References 

OFF 

Measurements  to  determine  the  status  of  the 
organization’s  process  development  and  improvement 
activities.  (L3-9,  Ml) 

OPD 

Data  on  the  resulting  work  products  (from  the  software 
processes).  (L3-20,  A5, 1) 

OPD 

Data  on  the  software  processes.  (L3-20,  A5, 1) 

OPD 

Measurements  to  determine  the  status  of  the 
organization's  process  definition  activities.  (L3-22, 

Ml) 

TP 

Measurements  to  determine  the  status  of  the  training 
program  activities.  (L3-34,  Ml) 

TP 

Measurements  to  determine  the  quality  of  the  training 
program.  (L3-35,  M2) 

ISM 

Project  measurement  data.  (L3-39,  Cl,  4) 

ISM 

Process  and  work  product  measurement  data.  (L3-43, 
A2,  1.3) 

ISM 

Measurement  data  needed  to  manage  the  software 
project.  (L3-44,  A4, 1) 

ISM 

Software  planning  data,  replanning  data,  and  actual 
measured  data.  (L3-47,  AS,  3) 

ISM 

Reuse  measurements  (reuse  of  requirements,  design, 
code,  test  plan,  and  test  procedures,  etc.).  (L3-48,  A6, 
3.1) 

ISM 

Measurements  to  determine  the  effectiveness  of  the 
integrated  software  management  activities.  (L3-56, 

Ml) 

SPE 

Data  on  defects  identified  in  peer  reviews.  (L3-78, 

A9) 

SPE 

Data  on  defects  identified  in  testing.  (L3-78,  A9) 

SPE 

Measurements  to  determine  the  functionality  and 
quality  of  the  software  products.  (L3-79,  Ml) 

SPE 

Measurements  to  determine  the  status  of  the  software 
product  engineering  activities.  (L3-80,  M2) 

IC 

Measurements  to  determine  the  status  of  the  intergroup 
coordination  activities.  (L3-91,  Ml) 

PR 

Data  on  the  conduct  and  results  of  the  peer  reviews. 
(L3-99,  A3) 

PR 

Measurements  to  determine  the  status  of  the  peer 
review  activities.  (L3-99,  Ml) 
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Chapter  6.  Managed  Level  (Level  4) 


Overview 


Introduction  This  chapter  contains  the  checklists  for  level  4  of  the  CMM. 


In  this  chapter  This  chapter  contains  the  following  sections: 


Section  Title 

Page 

Level  4  Policy  Checklists 

L4-Policy-l 

Level  4  Standards  Checklists 

L4-Standards-I 

Level  4  Process  Checklists 

L4-Process-l 

Level  4  Procedure  Checklists 

L4-Procedures-l 

Level  4  Summary 

L4-Summary-1 
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Level  4  Policy  Checklists 
Overview 


Introduction 


Purpose 


Checklist 

description 


In  this  section 


This  section  describes  the  explicit  policies  found  in  the  Capability  Maturity  Model 
at  maturity  level  4. 


The  purpose  of  the  policy  checklists  is  to  provide: 

•  Guidance  in  identifying  which  policies  are  recommended  by  the  CMM  at  level  4. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  policies  to  determine 
if  they  are  consistent  with  the  CMM  at  level  4. 

•  Information  that  can  be  used  to  develop  software  policies  so  that  they  are 
consistent  with  the  CMM  at  level  4. 


Each  checklist  contains  two  subsections:  the  KPA  policies  and  the  KPA  goals.  The 
table  below  describes  these  two  subsections  of  a  policy  checklist. 


Subsection 

Description 

Policy  checklist 

This  subsection  contains  criteria  that  the  organizational 
policy  can  be  evaluated  against.  These  criteria  must  be 
addressed  by  organizational  policy  to  be  consistent  with  the 
CMM. 

Policy  goals 

This  subsection  is  a  reminder  to  policy  designers  and 
evaluators  to  keep  in  mind  the  KPA  goals  when  developing 
the  policies  for  each  KPA.  The  goals  can  be  thought  of  as 
the  results  of  implementing  an  effective  policy. 

This  section  covers  the  following  policies: 


Policies 

See  Page 

Quantitative  process  management  policies 

L4-Policy-2 

Software  quality  management  policy 

L4-Policy-3 
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L4-Policy-1 


Quantitative  Process  Management  (QPM)  Policies 


QPM  policy  1 
checklist 


QPM  policy  2 
checklist 


QPM  policy 
goals 


The  project  follows  a  written  organizational  policy  for  measuring  and 
quantitatively  controlling  the  performance  of  the  project's  defined  software  process 
(L4-2,  Cl).  This  policy  typically  specifies  that; 


Description 

References 

Each  project  implements  a  documented  plan  to  bring  the 
project's  defined  software  process  under  quantitative  control. 
(L4-2,  Cl,  1) 

Sensitive  data  relating  to  individuals'  performance  are 
protected,  and  access  to  these  data  is  appropriately 
controlled.  (L4-3,  Cl,  2) 

The  organization  follows  a  written  policy  for  analyzing  the  process  capability  of 
the  organization's  standard  software  process  (L4-3,  C2).  This  policy  typically 
specifies  that-- 


T 

Description 

References 

The  projects'  measurements  of  process  performance  are 
analyzed  to  establish  and  maintain  a  process  capability 
baseline  for  the  organization's  standard  software  process. 
(L4-3,  C2,  1) 

The  process  capability  baseline  for  the  organization's 
standard  software  process  is  used  by  the  software  projects  in 
establishing  their  process  performance  goals.  (L4-4,  C2,  2) 

Implementation  of  effective  quantitative  process  management  policies  has  the 
following  results: 


Results  of  Effectively  Implementing  QPM  Policies 

References 

The  quantitative  process  management  activities  are  planned. 
(L4-2,  Gl) 

The  process  performance  of  the  project's  defined  software 
process  is  controlled  quantitatively.  (L4-2,  G2) 

The  process  capability  of  the  organization's  standard 
software  process  is  known  in  quantitative  terms.  (L4-2,  G3) 

L4-Policy-2 
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Software  Quality  Management  (SQM)  Policy 


SQM  policy  The  project  follows  a  written  organizational  policy  for  managing  software  quality 
checklist  (L4-20,  Cl).  This  policy  typically  specifies  that; 


V 

Description 

References 

The  project's  software  quality  management  activities  support 
the  organization’s  commitment  to  improve  the  quality  of  the 
software  products.  (L4-20,  Cl,  1) 

The  project  defines  and  collects  the  measurements  used  for 
software  quality  management  based  on  the  project's  defined 
software  process.  (L4-20,  Cl,  2) 

The  project  defines  the  quality  goals  for  the  software 
products  and  monitors  its  progress  towards  them.  (L4-20, 

Cl,  3) 

Responsibilities  for  software  quality  management  are 
defined  and  assigned  to  the  software  engineering  group  and 
other  software-related  groups.  (L4-21,  Cl,  4) 

Criteria  are  established  to  enable  the  groups  (software 
engineering  group  and  other  software-related  groups)  to 
determine  their  success  in  achieving  the  quality  goals  for  the 
software  products.  (L4-21,  Cl,  4.1) 

SQM  policy  Implementation  of  an  effective  software  quality  management  policy  has  the 
goals  following  results: 


> 

Results  of  Effectively  Implementing  SQM  Policy 

References 

The  project's  software  quality  management  activities  are 
planned.  (L4-20,  Gl) 

Measurable  goals  for  software  product  quality  and  their 
priorities  are  defined.  QA-IO,  G2) 

Actual  progress  toward  achieving  the  quality  goals  for  the 
software  products  is  quantified  and  managed.  (L4-20,  G3) 
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Level  4  Standards  Checklists 
Overview 


Introduction 


Definition 


Purpose 


What  the 
standards 
checklists  a/e 
not 


In  this  section 


This  section  describes  the  recommended  content  of  selected  work  products  in  the 
CMM  at  maturity  level  4. 


A  standards  checklist  describes  the  content  of  a  work  product  as  recommended  by 
the  CMM. 


The  purpose  of  the  standards  checklists  is  to  provide: 

•  Guidance  in  identifying  the  contents  of  standard  work  products  that  are 
recommended  by  the  CMM  at  level  4. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  standards  to 
determine  if  they  are  consistent  with  the  CMM  at  level  4. 

•  Information  that  can  be  used  to  develop  software  standards  that  are  consistent 
with  the  CMM  at  level  4. 


The  standards  checklists  contain  only  what  is  recommended  by  the  CMM,  and  are 
not  complete  standards  in  themselves.  For  example,  the  standard  for  the  software 
development  plan  (SDP)  contains  only  content  recommended  by  the  CMM.  Other 
sources  for  the  content  of  a  SDP  should  also  be  considered,  such  as  ANSI/IEEE  Std 
1058.1-1987,  DOD-STD-2167,  DI-MCCR-80030,  etc. 


This  section  covers  the  following  standards: 


Standard 

K?A 

See  Page 

Project's  quantitative  process  management  plan 

QPM 

L4-Standards-2 

Project's  software  quality  plan 

■^QM 

L4-Standards-3 
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L4-Standards-1 


Project's  Quantitative  Process  Management  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  project's  quantitative  process  management  plan: 


V 

Recommended  Content 

The  goals  and  objectives  of  the  quantitative  process  management  activities. 
(L4-7,  A2,  1) 

The  software  tasks  or  other  software  activities  that  will  be  measured  and 
analyzed.  (L4-8,  A2,  2) 

The  instrumentation  of  the  project’s  defined  software  process.  (L4-8,  A2,  3) 

The  quantitative  process  management  activities  to  be  performed  and  the 
schedule  for  these  activities.  (L4-8,  A2,  4) 

The  groups  and  individuals  responsible  for  the  quantitative  process 
management  activities.  (L4-8,  A2,  5) 

The  resources  required  to  perform  the  quantitative  process  management 
activities,  including  staff  and  tools.  (L4-8,  A2,  6) 

The  procedures  to  be  followed  in  performing  the  quantitative  process 
management  activities.  (L4  8,  A2,  7) 

L4-Standards-2 
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Project's  Software  Quality  Plan 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  project's  software  quality  plan; 


Recommended  Content 

The  points  in  the  process  where  software  quality  is  measured.  (L4-26,  A2, 

I) 

The  high-leverage  quality  goals  for  tne  software  products.  (L4-26,  A2,  2) 

The  actions  that  the  software  project  will  implement  to  improve  on  past 
quality  performance.  (L4-26,  A2,  3) 

The  activities  to  measure  software  product  quality.  (L4-26,  A2,  4) 

Quality  goals  for  software  work  products,  as  appropriate.  (L4-26,  A2,  5) 

The  actions  that  will  be  taken  when  the  software  product  quality  is  projected 
not  to  meet  the  quality  goals.  (L4-26,  A2,  6) 
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Level  4  Process  Checklists 
Overview 


Section  purpose 


In  this  section 


The  purpose  of  the  process  checklists  is  to  provide; 

•  Guidance  in  identifying  which  processes  are  required  by  the  CMM  at  level  4. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  processes  to 
determine  if  they  are  consistent  with  the  CMM  at  level  4. 

•  Information  that  can  be  used  to  develop  software  processes  that  are  consistent 
with  the  CMM  at  level  4. 


This  section  contains  checklists  for  the  following  key  process  areas: 


Key  Process  Area 

See  Page 

Quantitative  Process  Management 

L4-Process-3 

Software  Quality  Management 

L4-Process-31 
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Quantitative  Process  Management  (QPM)  Process 
QPM  Process  -  Overview 


QPM  process 
purpose 


QPM  process 
description 


The  purpose  of  Quantitative  Process  Management  is  to  control  the  process 
performance  of  the  software  project  quantitatively.  Software  process  performance 
represents  the  actual  results  achieved  from  following  a  software  process.  (L4-1) 


Quantitative  Process  Management  involves  establishing  goals  for  the  performance 
of  the  project's  defined  software  process,  which  is  described  in  the  Integrated 
Software  Management  key  process  area,  taking  measurements  of  the  process 
performance,  analyzing  these  measurements,  and  making  adjustments  to  maintain 
process  performance  within  acceptable  limits.  When  the  process  performance  is 
stabilized  within  acceptable  limits,  the  project's  defined  software  process,  the 
associated  measurements,  and  the  acceptable  limits  for  the  measurements  are 
established  as  a  baseline  and  used  to  control  process  performance  quantitatively. 

The  organization  collects  process  performance  data  from  the  software  projects  and 
uses  these  data  to  characterize  the  process  capability  (i.e.,  the  process  performance 
a  new  project  can  expect  to  attain)  of  the  organization's  standard  software  process, 
which  is  described  in  the  Organization  Process  Definition  key  process  area. 

Process  capability  describes  the  range  of  expected  results  from  following  a 
software  process  (i.e.,  the  most  likely  outcomes  that  are  expected  from  the  next 
software  project  the  organization  undertakes).  These  process  capability  data  are,  in 
turn,  used  by  the  software  projects  to  establish  and  revise  their  process  performance 
goals  and  to  analyze  the  performance  of  the  projects'  defined  software  processes. 


Continued  on  next  page 
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QPM  Process  ■  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L4-Process-5 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L4-Process-9 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L4-Process-l  1 

Activities 

Description  of  the  activities  of  the 
process. 

L4-Process-13 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L4-Process-15 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L4-Process-17 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L4-Process-23 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L4-Process-25 

Measurements 

Description  of  process  measurements. 

L4-Process-26 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L4-Process-27 

Training 

List  of  training. 

L4-Process-28 

Tools 

List  of  tools. 

L4-Process-29 

L4-Process-4 
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QPM  Process  -  Roles 


Roles  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

quantitative  process  management  process. 


V 

Role 

Activities  Participated  in... 

Reference 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process 

group) 

□  The  (group  that  is  responsible  for 
coordinating  the  quantitative  process 
management  activities  for  the 
organization)  is  either  part  of  the 
group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  or  its  activities  are 
closely  coordinated  with  that  group. 
(L4-4,  Abl,  1) 

□  The  project’s  quantitative  process 
management  plan  is  reviewed  by  the 
group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  the  soflv^are 
engineering  process  group).  (L4-7, 
A1.3) 

Group 

responsible  for 
coordinating 
the  quan¬ 
titative  process 
management 
activities  for 
the 

organization 

The  group  that  is  responsible  for 
coordinating  the  quantitative  process 
management  activities  for  the 
organization  is  either  part  of  the  group 
responsible  for  the  organization's  software 
process  activities  (e.g,,  software  engineering 
process  group)  or  its  activities  are  closely 
coordinated  with  that  group.  (L4-4,  Abl, 

1) 

Individuals 

implementing 

or  supporting 

quantitative 

process 

management 

The  individuals  implementing  or 
supporting  quantitative  process 
management  receive  required  training  to 
perform  these  activities.  (L4-6,  Ab4) 

Managers  of 
software- 
related  groups 

The  managers  and  task  leaders  of  the 
software  engineering  groups  and  other 
software-related  groups  perform  the 
project's  quantitative  process  management 
activities.  (L4-4,  Ab2,  1) 

Managers  of 
the  software 
engineering 
groups 

The  managers  and  task  leaders  of  the 
software  engineering  groups  and  other 
software-related  groups  perform  the 
project's  quantitative  process  management 
activities.  (L4-4,  Ab2,  1) 

Continued  on  next  page 
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QPM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
quantitative  process  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Project 

manager 

The  project  manager,  senior  managers, 
software  managers,  and  software  task 
leaders  receive  specialized  reports 
(documenting  the  results  of  the  software 
project’s  quantitative  process  management 
activities)  on  request.  (L4-12,  A6,  4) 

The  software  project’s  activities  for 
quantitative  process  management  are 
reviewed  with  the  project  manager  on  both 
a  periodic  and  event-driven  basis.  (L4-16, 
V2) 

Senior 

management 

□  The  software  managers,  software  task 
leaders,  and  senior  management 
receive  regular  reports  (documenting 
the  results  of  the  software  project’s 
quantitative  process  management 
activities)  appropriate  for  their  needs. 
(L4-12,  A6,  2) 

□  The  activities  for  quantitative  process 
management  are  reviewed  with  .senior 
management  on  a  periodic  basis.  (L4- 
15,  VI) 

Senior 

manager 

The  project  manager,  senior  managers, 
software  managers,  and  software  task 
leaders  receive  specialized  reports 
(documenting  the  results  of  the  software 
project’s  quantitative  process  management 
activities)  on  request.  (L4-12,  A6,  4) 

Software 

engineering 

group 

or 

Members  of 
the  software 
engineering 
group 

The  members  of  the  software  engineering 
group  and  other  software-related  groups 
receive  orientation  on  the  goals  and  value 
of  quantitative  process  management.  (L4- 
6,  Ab5) 

Continued  on  next  page 
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QPM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
quantitative  process  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 

manager 

□  The  software  managers,  software  task 
leaders,  and  senior  management  receive 
regular  reports  (documenting  the 
results  of  the  software  project’s 
quantitative  process  management 
activities)  appropriate  for  their  needs. 
(L4-12,  A6,  2) 

□  The  project  manager,  senior  managers, 
software  managers,  and  software  task 
leaders  receive  specialized  reports 
(documenting  the  results  of  the 
software  project’s  quantitative  process 
management  activities)  on  request. 
(L4-12,  A6,  4) 

Software- 
related  groups 

or 

Members  of 
software- 
related  groups 

The  members  of  the  software  engineering 
group  and  other  software-related  groups 
receive  orientation  on  the  goals  and  value 
of  quantitative  process  management.  (L4- 
6,  Ab5) 

Software 
quality 
assurance 
(SQA)  group 

□  The  software  quality  assurance  group 
receives  regular  reports  (documenting 
the  results  of  the  software  project’s 
quantitative  process  management 
activities)  appropriate  to  its  needs.  (L4- 
12,  A6,  3) 

□  The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and 
work  products  for  quantitative  process 
management  and  reports  the  results. 
(L4-16,  V3) 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L4-Process-7 


QPM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
quantitative  process  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software  task 
leaders 

□  The  software  managers,  software  task 
leaders,  and  senior  management 
receive  regular  reports  (documenting 
the  results  of  the  software  project’s 
quantitative  process  management 
activities)  appropriate  for  their  needs. 
(L4-12,  A6,  2) 

□  The  project  manager,  senior  managers, 
software  managers,  and  software  task 
leaders  receive  specialized  reports 
(documenting  the  results  of  the 
software  project’s  quantitative  process 
management  activities)  on  request. 
(L4-12,  A6.  4) 

Task  leaders 
of  other 
software- 
related  groups 

The  managers  and  task  leaders  of  the 
software  engineering  groups  and  other 
software-related  groups  perform  the 
project's  quantitative  process  management 
activities.  (L4-4,  Ab2,  1) 

1 _ 

Task  leaders 
of  the  software 
engineering 
groups 

The  managers  and  task  leaders  of  the 
software  engineering  groups  and  other 
software-related  groups  perform  the 
project’s  quantitative  process  management 
activities.  (L4-4,  Ab2,  1) 

L4-Process-8 
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QPM  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  quantitative  process  management  process. 


yl 

Input 

State 

References 

Project’s  quantitative 
process  management 
plan 

is  documented.  (L4-2,  CI,1) 

Sensitive  data  relating 
to  individuals' 
performance 

□  are  protected.  (L4-3,  Cl,  2) 

□  (access  to)  is  appropriately 
controlled.  (L4-3,  Cl,  2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  quantitative  process  management  process. 


V 

Condition 

References 

The  project  follows  a  written  organizational  policy  for 
measuring  and  quantitatively  controlling  the  performance  of 
the  project's  defined  software  process.  (L4-2,  Cl) 

[Refer  to  Level  4  Policies  for  additional  information 
regarding  QPM  policy.] 

The  organization  follows  a  written  policy  for  analyzing  the 
process  capability  of  the  organization's  standard  software 
process.  (L4-3,  C2) 

[Refer  to  Level  4  Policies  for  additional  information 
regarding  QPM  policy.] 

A  group  that  is  responsible  for  coordinating  the 
quantitative  process  management  activities  for  the 
organization  exists.  (L4-4,  Abl) 

□  The  group  that  is  responsible  for  coordinating  the 
quantitative  process  management  activities  for  the 
organization  is  either  part  of  the  group  responsible  for 
the  organization's  software  process  activities  (e.g., 
software  engineering  process  group)  or  its  activities  are 
closely  coordinated  with  that  group.  (L4-4,  Abl,  1) 

Adequate  resources  and  funding  are  provided  for  the 
quantitative  process  management  activities.  (L4-4,  Ab2) 

An  organization-wide  measurement  program  exists.  (L4-5, 
Ab2,  2) 

Tools  to  support  quantitative  process  management  are  made 
available.  (W-5,  Ab2,  3) 

Support  exists  for  collecting,  recording,  and  analyzing  data 
for  selected  process  and  product  measurements.  (L4-5, 

Ab3) 

Continued  on  next  page 
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QPM  Process  -  Entry  Criteria,  Continued 


General  entry 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  quantitative  process  management  process,  continued  from  the 
previous  page. 


Condition 

References 

The  individuals  implementing  or  supporting  quantitative 
process  management  receive  required  training  to  perform 
these  activities.  (L4-6,  Ab4) 

The  member^'-  of  the  software  engineering  group  and  other 
software-related  groups  receive  orientation  on  the  goals  and 
value  of  quantitative  process  management.  (L4-6,  Ab5) 

L4-Process-1 0 
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QPM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  quaniilallve  process 
management  process. 


Input 

Org.  Input 

References 

Actual  process  performance.  (L4-12,  A5, 

7) 

Defined  acceptable  limits  for  each 
measurement.  (L4-12,  A5.  7) 

Description  of  the  project's  defined 
software  process.  (L4-7,  Al,  1.6) 

Expected  mean  values  for  each 
measurement.  (L4-11,A5,  6) 

Expected  variance  values  for  each 
measurement.  (L4-11,A5,  6) 

Goals  of  the  organization’s  measurement 
program.  (L4-17,  V3,  3.4) 

Goals  of  the  quantitative  process 
management  activities.  (L4-7,  A2,  1) 

Measured  performance  of  other  projects’ 
defined  software  processes.  (L4-7,  Al, 

1.5) 

Objectives  of  the  organization's 
measurement  program.  (L4-17,  V3,  3.4) 

Objectives  of  the  quantitative  process 
management  activities.  (L4-7,  A2,  1 ) 

Organization's  measurement  goals.  (L4-9, 
A4,  1) 

Organization's  measurement  objectives. 
(L4-9,  A4,  1) 

Organization's  standard  software  process. 
(L4-7,  At,  1.3) 

Organization's  strategic  goals  for  product 
development  cycle  dme.  (L4-6,  Al,  1.1) 

Organization's  strategic  goals  for  product 
quality.  (L4-6,  Al,  1.1) 

Organization's  strategic  goals  for 
productivity.  (L4-6,  Al,  1.1) 

i 

Process  capability  baseline  of  the 
organization's  standard  software  process. 
(L4-3,  C2,  1) 

Continued  on  next  page 
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QPM  Process  -  Inputs,  continued 


Inputs, 

continued 


The  *able  below  lists  the  recommended  inputs  to  the  quantitative  process 
management  process,  continued  from  the  previous  page. 


V 

Input 

Org.  Input 

References 

Process  capability  trends  for  the 
organization's  standard  software  process. 
(L4-13,  A7,  4) 

Project's  defined  software  process.  (L4-2, 
Cl) 

Project’s  goals  for  product  development 
cycle  time  (L4-7,  Al,  1.4) 

Project’s  goals  for  software  product’s 
quality.  (L4-7,  Al,  1.4) 

Project’s  goals  for  productivity.  (L4-7, 

Al,  1.4) 

Project’s  measurement  of  process 
performance.  (L4-3,  C2,  1) 

Project’s  quantitative  process  management 
plan.  (L4-2,  Cl,  1) 

Schedule  for  quantitative  process 
management  activities  to  be  performed. 
(L4-8,  A2,  4) 

Sensitive  data  relating  to  individuals’ 
performance.  (L4-3,  Cl,  2) 

Software  project's  measurement  goals. 

(L4-9,  A4,  1) 

Software  project's  measurement  objectives. 
(L4-9.  A4,  1) 
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QPM  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  quantitative  process 
management  process. 


V 

Activities 

References 

The  software  project's  plan  for  quantitative  process 
management  is  developed  according  to  a  documented 
procedure.  (L4-6,  Al) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 

The  software  project's  quantitative  process  management 
activities  are  performed  in  accordance  with  the  project's 
quantitative  process  management  plan.  (L4-7,  A2) 

The  strategy  for  the  data  collection  and  the  quantitative 
analyses  to  be  performed  are  determined  based  on  the 
project's  defined  software  process.  (L4-8,  A3) 

The  measurement  data  used  to  control  the  project's  defined 
software  process  quantitatively  are  collected  according  to  a 
documented  procedure.  (L4-9,  A4) 

(Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 

The  project's  defined  software  process  is  analyzed  and 
brought  under  quantitative  control  according  to  a 
documented  procedure.  (L4-10,  A5) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 

Reports  documenting  the  results  of  the  software  project's 
quantitative  process  management  activities  are  prepared  and 
distributed.  (L4-12,  A6) 

The  process  capability  baseline  for  the  organization's 
standard  software  process  is  established  and  maintained 
according  to  a  documented  procedure.  (L4'13,  A7) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 

Measurements  are  made  and  used  to  determine  the  status  of 
the  activities  for  quantitative  process  management.  (L4-15, 
Ml) 

The  activities  for  quantitative  process  management  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L4- 
15,  VI) 

Continued  on  next  page 
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QPM  Process  -  Activities,  Continued 


Activities 

continued 


The  table  below  lists  the  recommended  activities  for  the  quantitative  process 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  software  project's  activities  for  quantitative  process 
management  are  reviewed  with  the  project  manager  on  both 
a  periodic  and  event-driven  basis.  (L4-16,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  quantitative  process 
management  and  reports  the  results.  (L4-16,  V3) 

(Refer  to  QPM  Process  Reviews  and  Audits  for  additional 
information.] 
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QPM  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  quantitative 
process  management  process. 


Output 

Org.  Output 

References 

Acceptable  limits  for  each  measurement. 
(L4-11,  A5,  5) 

Actual  measurement  data.  (L4-12,  A5, 

8.2) 

Actual  values  of  each  measurement.  (L4- 
11,  A5,  6) 

Changes  to  the  organization's  standard 
software  process.  (L4-15,  A7,  7) 

Data  collection  points.  (L4-9,  A3,  3) 

Data  for  selected  process  measurements  or 
measurement  data  on  the  process  activities 
throughout  the  project’s  defined  software 
process.  (L4-5,  Ab3) 

Data  for  selected  product  measurements. 
(L4-5,  Ab3) 

Definitions  of  measurement  data  (used  to 
control  the  project’s  defined  software 
process  quantitatively).  (L4-9,  A4,  2) 

Expected  values  for  mean  (for  each 
measurement).  (L4-11,A5,  4) 

Expected  values  for  variance  (for  each 
measurement).  (L4-1 1,  A5,  4) 

Goals  of  the  quantitative  process 
management  activities.  (L4-7,  A2,  1) 

Intended  use  and  analysis  of  each 
measurement.  (L4-9,  A4,  2) 

Measurement  data  used  to  control  the 
project's  defined  software  process 
quantitatively.  (L4-9,  A4) 

Measurements  (to  determine  the  status  of 
the  quantitative  process  management 
activities).  (L4-15,  Ml) 

Objectives  of  the  quantitative  process 
management  activities.  (L4-7,  A2,  1) 

Process  capability  baseline  of  the 
organization's  standard  software  process. 
(L4-3,  C2,  1) 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L4-Process-15 


QPM  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  quantitative 
process  management  process,  continued  from  the  previous  page. 


/ 

\ 

Output 

Org.  Output 

References 

Process  control  points  at  which  (each 
measurement  that  is  used  to  control  the 
project’s  defined  software  process 
quantitatively)  will  be  collected.  (L4-9,  A4, 
2) 

Projects'  measurements  of  process 
performance.  (L4-3,  C2,  1) 

Project’s  process  performance  baseline. 
(L4-11.  A5,  5) 

Project’s  process  performance  goals.  (LA- 
4,  C2,  2) 

j 

Project's  software  process  data.  (L4-13, 

A7.  1) 

Project’s  quantitative  process  management 
plan.  (L4-6,  Al) 

Quantitative  process  management  data. 
(L4-16,  V3,  3) 

Reports  documenting  the  results  of  the 
software  project's  quantitative  process 
management  activities.  (L4-12,  A6) 

Results  of  software  quality  assurance  group 
reviews  and/cr  audits  of  the  activities  and 
work  products  for  quantitative  process 
management.  (L4-16,  V3) 

Results  of  the  data  analysis.  (L4-12,  A6,  1) 

Schedule  for  quantitative  process 
management  activities  to  be  performed. 
(L4-8,  A2,  4) 

Strategy  for  the  data  collection  and  the 
quantitative  analyses  to  be  performed. 
(L4-8,  A3) 
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QPM  Process  -  Exit  Criteria 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
exit  criteria  to  exit  the  quantitative  process  management  process. 


Output 

State 

References 

Acceptable  limits  for 
each  measurement 

□  are  defined.  (L4-11,A5,  5) 

□  have  baselines  established  when 
the  project’s  defined  software 
process  is  controlled 
quantitatively.  (L4-12,  A5,  8.3) 

Actual  measurement 
data 

have  baselines  established  when  the 
project’s  defined  software  process  is 
controlled  quantitatively.  (L4-12, 

A5,  8.2) 

Actual  values  of  each 
measurement 

are  compared  to  the  expected  values 
of  the  mean  and  variance.  (L4-11, 

A5,  6) 

Changes  to  the 
organization's 
standard  software 
process 

□  are  tracked.  (L4-15,  A7,  7) 

□  are  analyzed  to  assess  their 
effects  on  the  process  capability 
baseline.  (L4-15,  A7,  7) 

Data  for  selected 

process 

measurements 

or 

Measurement  data  on 
the  process  activities 
throughout  the 
project’s  defined 
software  process 

□  are  identified.  (L4-11,  AS,  2) 

□  are  collected.  (L4-11,A5,  2) 

□  are  analyzed.  (L4-11,  A5,  2) 

□  appropriately  characterize  the 
process  they  represent.  (L4-11, 
A5,  3) 

Definitions  of 
measurement  data 
(used  to  control  the 
project’s  defined 
software  process 
quantitatively) 

□  are  defined.  (L4-9,  A4,  2) 

□  have  baselines  established  when 
the  project’s  defined  software 
process  is  controlled 
quantitatively.  (L4-12,  A5,  8.1) 

Expected  values  (for 
mean  for  each 
measurement) 

are  specified  for  each  measurement. 
(L4-11,  A5.  4) 

Expected  values  (for 
variance  for  each 
measurement) 

are  specified  for  each  measurement. 
(L4-11,  A5,  4) 

Intended  use  and 
analysis  of  each 
measurement 

is  defined.  (L4-9,  A4,  2) 
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QPM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  quantitative  process  management  process,  continued  from  the  previous 
page. 


T' 

Output 

State 

References 

Measurement  data 
used  to  control  the 
project's  defined 
software  process 
quantitatively 

□  are  collected  according  to  a 
documented  procedure.  (L4-9, 
A4) 

□  support  the  organization's  and 
the  software  project's 
measurement  goals  and 
objectives.  (L4-9,  A4,  1) 

□  are  defined.  (L4-9,  A4,  2) 

□  are  chosen  from  the  entire 
software  life  cycle  (e.g.,  both  the 
development  and  post¬ 
development  stages).  (L4-9,  A4, 
3) 

□  cover  the  properties  of  the  key 
software  process  activities  and 
major  software  work  products. 
(L4-10,  A4,  4) 

□  are  uniformly  collected  across 
the  software  projects  when  the 
data  relate  to  the  organization's 
standard  software  process.  (L4- 
10.  A4,  5) 

□  aie  a  natural  result  of  the 
software  activities  where  possible. 
(U-10,  A4,  6) 

□  are  selected  to  support 
predefined  analysis  activities. 
(L4-10,  A4,  7) 

□  are  independently  assessed  for 
validity.  (L4-10,  A4,  8) 

□  are  stored  in  the  organization's 
software  process  database  as 
appropriate.  (L4-10,  A4,  9) 

Measurements  (to 
determine  the  status 
of  the  activities  for 
quantitative  process 
management) 

□  are  made.  (L4-15,  MI) 

□  are  used.  (L4-15,  Ml) 
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QPM  Process  -  Exit  Criteria,  continued 


Output-based  The  CMM  reconunends  that  outputs  satisfy  the  states  described  in  the  table  below 
exit  criteria,  to  exit  the  quantitative  process  management  process,  continued  from  the  previous 

continued  page. 


R" 

Output 

State 

References 

Process  capability 
baseline  of  the 
organization’s 
standard  software 
process 

□  is  established  according  to  a 
documented  procedure.  (L4-13, 
A7) 

□  is  maintained  according  to  a 
documented  procedure.  (L4-13, 
A7) 

□  is  documented.  (L4-13,  A7,  3) 

□  is  managed  and  controlled.  (L4- 
14,  A7,  5) 

Process  control 
points  at  which  (each 
measurement  that  is 
used  to  control  the 
project’s  defined 
software  process 
quantitatively)  will  be 
collected 

are  defined.  (L4-9,  A4,  2) 

Projects' 

measurements  of 
process  performance 

are  analyzed  to  establish  and 
maintain  a  process  capability 
baseline  for  the  organization's 
standard  software  process.  (L4-3, 

C2,  1) 

Project’s  process 
performance  baseline 

□  is  established.  (L4-11,A5,  5) 

□  is  managed  and  controlled.  (L4- 

12,  A5,  9) 

□  is  incorporated,  as  appropriate, 
into  the  process  capability 
baseline  for  the  organization’s 
standard  software  process.  (L4- 

13,  A7,  2) 

□  (new)  is  established  for  a 
software  project  substantially 
different  from  past  projects  as 
part  of  tailoring  the 
organization's  standard  software 
process.  (L4-14,  A7,  6) 

1 

Project’s  process 
performance  goals 

are  established.  (L4-4,  C2,  2) 
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QPM  Process  -  Exit  Criteria,  Continued 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
exit  criteria,  to  exit  the  quantitative  process  management  process,  continued  from  the  previous 

continued  page. 


T 

Output 

State 

References 

Project's  software 
process  data 

as  summarized  in  its  process 
performance  baseline,  are  recorded 
in  the  organization's  software  process 
database.  (L4-13,  A7,  1) 

Project’s  quantitative 
process  management 
plan 

□  is  developed  according  to  a 
documented  procedure.  (L4-6, 
Al) 

□  is  based  on;  (L4-6,  Al,  1) 

□  the  organization's  strategic 
goals  for  product  quality, 
productivity,  and  product 
development  cycle  time; 

□  the  organization's 
measurement  program; 

□  the  organization's  standard 
software  process; 

□  the  project’s  goals  for  the 
software  product's  quality, 
productivity,  and  product 
development  cycle  time; 

□  the  measured  performance  of 
other  projects’  defined 
software  processes;  and 

□  the  description  of  the 
project’s  defined  sofiwarp 
process. 

□  undergoes  peer  review.  (L4-7, 
Al,2: 

□  is  reviewed  by  the  group 
responsible  for  the 
organization’s  software  process 
activities  (e.g.,  the  software 
engineering  process  group). 
(L4-7,  Al,  3) 

□  is  managed  and  controlled.  (L4- 
7,  Al,  4) 

Continued  on  next  page 
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QPM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


General  Exit 
Criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  quantitative  process  management  process,  continued  from  the  previous 
page. 


V 

Output 

State 

References 

Reports  documenting 
the  results  of  the 
software  project's 
quantitative  process 
management 
activities 

□  are  prepared.,  (L4-12,  A6) 

□  are  distributed.  (L4-12,  A6) 

Results  of  software 
quality  assurance 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  quantitative 
process  management 

are  reported.  (L4-16,  V3) 

Results  of  the  data 
analysis 

are  reviewed  with  those  affected  by 
the  data  before  they  are  reported  to 
anyone  else.  (L4-12,  A6,  1) 

Strategy  for  me  data 
collection  and  the 
quantitative  analyses 
to  be.  performed 

are  determined  based  on  the  project’s 
defined  software  process.  (L4-8,  A3) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  quantitative  process  management  process. 


Condition 

References 

Each  project  implements  a  documented  plan  to  bring  the 
project's  defined  software  process  under  quantitative  control. 
(L4-2,  Cl,  1) 

The  process  capability  baseline  for  the  organization's 
standard  software  process  is  used  by  the  software  projects  in 
establishing  their  process  performance  goals.  (L4-4,  C2,  2) 

The  software  project's  quantitative  process  management 
activities  are  performed  in  accordance  with  the  project's 
quantitative  process  management  plan.  (L4-7,  A2) 
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QPM  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  quantitative  process  management  process,  continued  from  the  previous 
page. 


T 

Condition 

References 

The  strategy  for  the  data  collection  and  the  quantitative 
analyses  to  be  performed  are  determined  based  on  the 
project’s  defined  software  process.  (L4-8,  A3) 

The  attributes  of  the  project's  defined  software  process  that 
are  considered  include: 

□  The  tasks,  the  activities,  and  their  relationships  to  each 
other. 

□  The  software  work  products  and  their  relationships  to 
each  other  and  to  the  project’s  defined  software  process. 

□  The  process  control  points  and  data  collection  points. 

The  project’s  defined  software  process  is  analyzed  and 
brought  under  quantitative  control  according  to  a 
documented  procedure.  (L4-10,  A5) 

The  software  managers,  software  task  leaders,  and  senior 
management  receive  regular  reports  appropriate  for  their 
needs.  (L4-12,  A6,  2) 

The  software  quality  assurance  group  receives  regular 
reports  (documenting  the  results  of  the  software  project’s 
quantitative  process  management  activities)  appropriate  to  its 
needs.  (L4-12,  A6,  3) 

The  project  manager,  senior  managers,  software 
managers,  and  software  task  leaders  receive  specialized 
reports  (documenting  the  results  of  the  software  project’s 
quantitative  process  management  activities)  on  request.  (L4- 
12,  A6,  4) 

Process  capability  trends  for  the  organization’s  standard 
software  process  are  examined  to  predict  likely  problems  or 
opportunities  for  improvements.  (L4-13,  A7,  4) 

The  activities  for  quantitative  process  management  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L4- 
15,  VI) 

The  software  project’s  activities  for  quantitative  process 
management  are  reviewed  with  the  project  manager  on  both 
a  periodic  and  event-driven  basis.  (L4-16,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  quantitative  process 
management  and  reports  the  results.  (L4-16,  V3) 
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QPM  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  quantitative 
process  management  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  project’s  quantitative  process 
management  plan  undergoes  peer  review. 
(L4-7,  Al,  2) 

Not  specified  in 
the  CMM 

The  project’s  quantitative  process 
management  plan  is  reviewed  by  the  group 
responsible  for  the  organization's 
software  process  activities  (e.g.,  the 
software  engineering  process  group). 
(L4-7,  Al,  3) 

Group 

responsible  for 
the 

organization's 
software 
process 
activities  (e.g., 
the  software 
engineering 
process  group) 

The  results  of  the  data  analysis  are 
reviewed  with  those  affected  by  the  data 
before  they  are  reported  to  anyone  else. 
(L4-12,  A6,  1) 

Not  specified  in 
the  CMM 

The  activities  for  quantitative  process 
management  are  reviewed  with  senior 
management  on  a  periodic  basis.  (M-id, 
VI) 

Senior 

management 

The  software  project's  activities  for 
quantitative  process  management  are 
reviewed  with  the  project  manager  on  both 
a  periodic  and  event-driven  basis.  (L4-16, 
V2) 

Project 

manager 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L4-Process-23 


QPM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  quantitative 
process  management  process,  continued  from  the  previous  page. 


V 

Review  or  Audit 

Review 

Participants 

References 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  quantitative  process 
management  and  reports  the  results.  (L4- 
16,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify  that; 

□  The  plans  for  the  quantitative  process 
management  activities  are  followed. 

□  The  procedures  for  quantitative  process 
management  are  followed. 

□  The  collection  and  analysis  of 
quantitative  process  management  data 
are  performed  as  required,  including 
verification  that: 

□  the  needed  data  exist, 

□  the  needed  data  are  collected, 

□  the  data  collected  are  needed, 

□  the  data  collected  support  the  goals 
and  objectives  of  the  organization’s 
measurement  program, 

□  the  cost  of  collecting  the  data  is 
justified  by  the  usefulness  of  the 
data, 

□  the  data  are  collected  at  the  correct 
point  in  the  software  life  cycle, 

□  the  data  are  accurate  and  correct, 

□  the  data  are  timely,  and 

□  the  confidentiality  of  the  data  is 
properly  protected. 

Software 

quality 

assurance 

group 

L4-Process-24 


CMU/SEI-94-HB-1 


QPM  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  quantitative  process  management  process. 


V 

Work  Products  Managed  and  Controlled 

References 

Project’s  quantitative  process  management  plan.  (L4-7,  Al, 
4) 

Process  performance  baseline  for  the  software  project.  (L4- 
12,  A5,  9) 

Process  capability  baseline  for  the  organization's  standard 
software  process.  (L4-14,  A7,  5) 

CMU/SEI-94-HB-1 


L4-Process-25 


QPM  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  quantitative  process 
management  process. 


Measurements 

References 

Measurements  to  determine  the  status  of  the  activities  for 

quantitative  process  management.  (L4-15,  Ml) 

Examples  of  measurements  include: 

□  The  cost  over  time  for  the  quantitative  process 
management  activities,  compared  to  the  plan. 

□  The  accomplishment  of  schedule  milestones  for 
quantitative  press  management  activities,  compared  to 
the  approved  plan  (e.g.,  establishing  the  process 
measurements  to  be  used  on  the  project,  determining 
how  the  process  data  will  be  collected,  and  collecting  the 
process  data). 
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QPM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  quantitative  process  management  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


V 

Documented  Procedure(s) 

References 

The  software  project's  plan  for  quantitative  process 
management  is  developed  .•’ccording  to  a  documented 
procedure.  (L4-6,  Al) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 

The  measurement  data  used  to  control  the  project's  defined 
software  process  quantitatively  are  collected  according  to  a 
documented  procedure.  (L4-9,  A4) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 

The  project's  defined  software  process  is  analyzed  and 
brought  under  quantitative  control  according  to  a 
documented  procedure.  (L4-10,  A5) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 

The  process  capability  baseline  for  the  organization's 
standard  software  process  is  established  and  maintained 
according  to  a  documented  procedure.  (L4-13,  A7) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 
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Training 


The  table  below  lists  the  training  recommended  for  the  quantitative  process 
management  process. 


V 

Training 

References 

The  individuals  implementing  or  supporting  quantitative 
process  management  receive  required  training  to  perform 
these  activities.  (L4-6,  Ab4) 

The  members  of  the  software  engineering  group  and  other 
software-related  groups  receive  orientation  on  the  goals  and 
value  of  quantitative  process  management.  (L4-6,  Ab5) 
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QPM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  quantitative  process 
management  process. 


Tools 

References 

Tools  to  support  quantitative  process  management.  (L4-5, 
Ab2,  3) 

Examples  of  support  tools  include; 

□  software  source  code  analyzers, 

□  automated  test  coverage  analyzers, 

□  database  systems, 

□  quantitative  analysis  packages,  and 

□  problem  tracking  packages. 

Organization’s  software  process  database.  (L4-10,  A4,  9) 
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Software  Quality  Management  (SQM)  Process 
SQM  Process  -  Overview 


SQM  process 
purpose 


SQM  process 
description 


The  purpose  of  Software  Quality  Management  is  to  develop  a  quantitative 
understanding  of  the  quality  of  the  project's  software  products  and  achieve  specific 
quality  goals.  (L4-19) 


Software  Quality  Management  involves  defining  quality  goals  for  the  software 
products,  establishing  plans  to  achieve  these  goals,  and  monitoring  and  adjusting 
the  software  plans,  software  work  products,  activities,  and  quality  goals  to  satisfy  the 
needs  and  desires  of  the  customer  and  end  user  for  high  quality  products. 

The  practices  of  Software  Quality  Management  build  on  the  practices  of  the 
Integrated  Software  Management  and  Software  Product  Engineering  key  process 
areas,  which  establish  and  implement  the  project's  defined  software  process,  and  the 
Quantitative  Process  Management  key  process  area,  which  establishes  a  quantitative 
understanding  of  the  ability  of  the  project's  defined  software  process  to  achieve  the 
desired  results. 

Quantitative  goals  are  established  for  the  software  products  based  on  the  needs  of 
the  organization,  the  customer,  and  the  end  users.  So  that  these  goals  may  be 
achieved,  the  organization  establishes  strategies  and  plans,  and  the  project 
specifically  adjusts  its  defined  software  process,  to  accomplish  the  quality  goals. 
(L4-19) 


Continued  on  next  page 
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Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L4-Process-33 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L4-Process-36 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L4-Process-37 

Activities 

Description  of  the  activities  of  the 
process. 

L4-Process-39 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L4-Process-42 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L4-Process-44 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L4-Process-50 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L4-Process-5 1 

Measurements 

Description  of  process  measurements. 

L4-Process-52 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L4-Process-53 

Training 

List  of  training. 

L4-Proccss-54 

Tools 

List  of  tools. 

L4-Process-55 
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SQM  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  management  process. 


Role 

Activities  Participated  in... 

Reference 

Affected 

groups 

□  The  software  quality  plan  is  reviewed 
by  affected  groups  and  individuals. 
(L4-24,  Al,  8) 

□  The  software  quality  plan  is  available  to 
all  affected  groups  and  individuals. 
(L4-25,  Al,  11) 

Affected 

individuals 

□  The  software  quality  plan  is  reviewed 
by  affected  groups  and  individuals. 
(L4-24.  Al.  8) 

□  The  software  quality  plan  is  available  to 
all  affected  groups  and  individuals. 
(L4-25,  Al,  11) 

Customer 

The  customer  and  end  users  participate  in 
quality  tradeoff  decisions,  as  appropriate. 
(L4-30,  A4,  5.3) 

End  users 

The  customer  and  end  users  participate  in 
quality  tradeoff  decisions,  as  appropriate. 
(L4-30,  A4,  5.3) 

Individuals 

implementing 

and 

supporting 

software 

quality 

management 

The  individuals  implementing  and 
supporting  software  quality  management 
receive  required  training  to  perform  their 
activities.  (L4-22,  Ab2) 

Project 

manager 

The  activities  for  software  quality 
management  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L4-31,  V2) 

Senior 

management 

□  Senior  management  reviews  the 
software  quality  plans.  (L4-25,  Al,  9) 

□  The  activities  for  software  quality 
management  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L4- 
31,  VI) 

Continued  on  next  page 
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SQM  Process  -  Roles,  Continued 


Roltis, 

convinued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Software 

engineering 

group 

or 

Members  of 
the  software 
engineering 
group 

□  Responsibilities  for  software  quality 
management  are  defined  and  assigned 
to  the  software  engineering  group  and 
other  software-related  groups.  (L4-21, 
Cl,  4) 

□  Criteria  are  established  to  enable 
the  groups  to  determine  their 
success  in  achieving  the  quality 
goals  for  the  software  products. 
(L4-21,  Cl,  4.1) 

□  The  members  of  the  software 
engineering  group  and  other  software- 
related  groups  receive  required  training 
in  software  quality  management.  (L4- 
22,  Ab3) 

Software- 
related  groups 

or 

Members  of 
the  software- 
related  groups 

□  Responsibilities  for  software  quality 
management  are  defined  and  assigned 
to  the  .softw.are  engineering  group  and 
other  software-related  groups.  (L4- 
21,  Cl,  4) 

□  Criteria  are  established  to  enable 
the  groups  to  determine  their 
success  in  achieving  the  quality 
goals  for  the  software  products. 
(1.4-21,  Cl,  4.1) 

□  The  members  of  the  software 
engineering  group  and  other  software- 
related  groups  receive  required 
training  in  software  quality 
management.  (L4-22,  Ab3) 

Specialty 
engineers  in 
areas  such  as 
safety  and 
reliability 

Specialty  engineers  in  areas  such  as  safety 
and  reliability  are  available  to  help  set  the 
software  quality  goals  and  review  progress 
towards  the  goals.  (L4-21,  Abl,  1) 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  quality  management 
and  reports  the  results.  (L4-32,  V3) 

Continued  on  next  page 
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SQM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
software  quality  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Subcontractor 

The  software  project's  quantitative  quality 
goals  for  the  products  are  allocated 
appropriately  to  the  subcontractors 
delivering  software  products  to  the  project. 
(L4-30,  A5) 

Team 

performing  the 
software  task 

The  software  tasks  are  planned  and 
performed  to  address  the  project's  software 
quality  goals.  At  the  beginning  of  a 
software  task,  the  team  performing  the 
task:  (U-29,  A4,  1) 

□  reviews  the  quality  goals  for  the 
software  product, 

□  determines  the  quality  goals  applicable 
to  the  software  task, 

□  identifies  its  plans  to  achieve  the 
software  quality  goals,  and 

□  reviews  changes  made  to  the  process  to 
meet  the  software  quality  goals. 
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SQM  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  in  the  software  quality  management 
process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  software  quality  management  process. 


Condition 

References 

The  project  follows  a  written  organizational  policy  for 
managing  software  quality.  (L4-20,  Cl) 

[Refer  to  I^vel  4  Policies  for  additional  infcmriation 
regarding  SQM  policy.] 

Adequate  resources  and  funding  are  provided  for  managing 
the  quality  of  the  software  products.  (L4-21,  Abl) 

Specialty  engineers  in  areas  such  as  safety  and  reliability 
are  available  to  help  set  the  software  quality  goals  and  review 
progress  towards  the  goals.  (L4-21,  Abl,  1) 

Tools  to  support  predicting,  measuring,  tracking,  and 
analyzing  software  quality  aie  made  available.  (L4-21,  Abi, 
2) 

The  individuals  implementing  and  supporting  software 
quality  management  receive  required  training  to  perform 
their  activities.  (L4-22,  Ab2) 

The  members  of  the  software  engineering  group  and  other 
software-related  groups  receive  required  training  in 
software  quality  management.  (L4-22,  Ab3) 
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SQM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  software  quality  management 
process. 


Input 

Org.  Input 

References 

Alternative  software  quality  goals.  (L4-30, 
A4,  5.2) 

Characteristic(s)  of  software  product 
quality  (that  describe  how  well  the  software 
product  will  perform  or  how  well  it  can  be 
developed  and  maintained).  (L4-27,  A3, 

3) 

Cost  for  achieving  the  software  quality 
goals.  (L4-30,  A4,  5.1) 

Desired  values  (for  each  characteristic  of 
software  product  quality).  (L4-27,  A3,  3) 

Long-term  business  strategies.  (L4-30,  A4, 
5.2) 

Plans  (software  quality)  for  previous  or 
current  projects  in  the  organization.  (L4- 
24,  Al,  5) 

Points  in  the  process  where  software  quality 
is  measured.  (L4-26,  A2,  1) 

Products'  quantitative  quality  goals.  (L4- 
29,  A4) 

Project's  defined  software  process.  (L4-20, 
Cl,  2) 

Project's  software  quality  goals.  (L4-29, 

A4,  1) 

Project's  software  quality  plan  or  software 
quality  plan.  (L4-25,  A2) 

[Refer  to  Level  4  Standards  for  additional 
information  regarding  the  project's 
software  quality  plan.] 

Quality  goals  for  the  software  life-cycle 
stages.  (L4-29,  A3,  6) 

Quality  goals  for  the  software  products. 
(L4-21,C1,4.1) 

_ I 

Quality  measurements  (of  the  project’s 
Software  products).  (L4-30,  A4,  3) 

Continued  on  next  page 
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SQM  Process  >  Inputs,  Continued 


Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  software  quality  management 
process,  continued  from  the  previous  page. 


V 

Input 

Org.  Input 

References 

Quality  plans  of  the  organization.  (L4-24, 
Al,4) 

Required  values  (for  each  characteristic  of 
software  product  quality).  (L4-27,  A3,  3) 

Short-term  priorities..  (L4-30.  A4,  5.2) 

Significant  changes  to  the  allocated 
requirements.  (L4-24,  Al,  6) 

Software  plans.  (L4-30,  A4,  5.4) 

Software  project's  quantitative  quality  goals 
for  the  products.  (L4-30,  A5) 

Software  quality  goals.  (L4-23,  Al,  2) 

Softwaie  quality  needs  of  the  customer. 
(L4-23,  Al,  1) 

Software  quality  needs  of  the  end  users. 
(L4-23,  Al,  1) 

Software  quality  needs  of  the  organization. 
(L4-23,  Al,  1) 

Software  quality  priorities  of  the  customer. 
(L4-23,  Al,  2) 

Software  quality  priorities  of  the  end  users. 
(L4-23,  Al,  2) 

Software  quality  priorities  of  the 
organization.  (L4-23,  Al,  2) 

Software  work  products  or  work  products. 
(L4-30,  A4.  5.4) 

Subcontractor  delivered  software  products 
(to  the  project).  (L4-30,  A5) 

System  requirements  allocated  to  software 
or  allocated  requirements.  (L4-23,  Al,  2) 
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SQM  Process  -  Activities 


Activities 


The  table  below  lists  the  recommendec'  activities  for  the  software  quality 
management  process. 


Activities 

References 

The  project's  software  quality  plan  is  developed  and 
maintained  according  to  a  documented  procedure.  (L4-23, 
Al) 

[Refer  to  Level  4  Pncedure  Checklists  for  additional 
information.] 

The  project's  software  quality  plan  is  the  basis  for  the 
project's  activities  for  software  quality  management.  (L4-25, 
A2) 

The  project's  quantitative  quality  goals  for  the  software 

products  are  defined,  monitored,  and  revised  throughout  the 

software  life  cycle.  (L4-27,  A3) 

□  Characteristics  of  product  quality  that  describe  hov.'  well 
the  software  product  will  perfomi  or  how  well  it  can  be 
developed  and  maintained  are  identified. 

□  The  measurements  used  to  quantify  the  characteristics  of 
software  product  quality  are  identified. 

□  For  each  characteristic  of  software  product  quality, 
measurable,  numeric  values,  based  on  the  required  and 
desired  values,  are  selected  as  quality  goals  for  the 
product. 

□  Quality  goals  for  the  software  products  are  documented 
in  the  project's  software  quality  plan. 

□  Quality  goals  for  each  software  life-cycle  stage  are 
defined  and  documented. 

□  Quality  goals  for  the  software  products  and  software  life- 
cycle  stages  are  revised  as  understanding  of  the  products 
and  understanding  of  the  organization's,  customer's,  and 
end  users'  needs  evolve. 

Continued  on  next  page 
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SQM  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  quality 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

I 

The  quality  of  the  project's  software  products  is  measured, 

analyzed,  and  compared  to  the  products’  quantitative  quality 

goals  on  an  event-driven  basis.  (L4-29,  A4) 

□  The  software  tasks  are  planned  and  performed  to  address 
the  project's  software  quality  goals.  At  the  beginning  of 
a  software  task,  the  team  performing  the  task: 

□  reviews  the  quality  goals  for  the  software  product, 

□  determines  the  quality  goals  applicable  to  the 
software  task, 

□  identifies  its  plans  to  achieve  the  software  quality 
goals,  and 

□  reviews  changes  made  to  the  process  to  meet  the 
software  quality  goals. 

□  The  quality  of  the  software  work  products  of  each 
software  life-cycle  stage  are  measured. 

□  The  quality  measurements  are  analyzed  and  compared 
to  the  software  quality  goals  to  determine  whether  the 
quality  goals  are  satisfied. 

□  Appropriate  actions,  consistent  with  the  software  quality 
plan,  are  taken  to  bring  the  quality  measures  of  the 
products  in  line  with  the  software  quality  goals. 

□  When  it  is  determined  that  the  software  quality  goals 
conflict  (that  is,  one  goal  cannot  be  achieved  without 
compromising  another  goal),  actions  are  taken  to  resolve 
the  conflict., 

□  Tne  cost  for  achieving  the  software  quality  goals  is 
analyzed. 

□  Alternative  software  quality  goals  are  considered  in 
light  of  long-term  business  strategies  as  well  as  short¬ 
term  priorities. 

□  The  customer  and  end  u.sers  participate  in  quality 
tradeoff  decisions,  a>  appropriate. 

□  The  software  work  products  and  plans  are  revised,  as 
appropriate,  to  reflect  the  results  of  the  tradeoffs. 

I 

The  software  project's  quantitative  quality  goals  for  the 
products  are  allocated  appropriately  to  the  subcontractors 
delivering  software  products  to  the  project.  (L4-30,  A5) 

Continued  on  next  pof-e 
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SQM  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  software  quality 
management  process,  continued  from  the  previous  page. 


Activities 

References 

Measurements  are  made  and  used  to  determine  the  status  of 
the  software  quality  management  activities.  (L4-31,  Ml) 

The  activities  for  software  quality  management  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L4-31,  VI) 

The  activities  for  software  quality  management  are  reviewed 
with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis.  (L4-3I,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  quality 
management  and  reports  the  results.  (L4-32,  V3) 

(Refer  to  SQM  Process  Reviews  and  Audits  for  additional 
information.] 
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Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  software  quality 
management  process. 


Output 

Org.  Output 

References 

Capability  of  the  project's  defined  software 
process  to  satisfy  the  software  quality 
goals.  (L4-24.  A1.3) 

Characteristics  of  product  quality  that 
describe  how  well  the  software  product  will 
perform  or  ho\.  v?ll  it  can  be  developed 
and  maintained.  <’L4-27,  A3,  1) 

Criteria  to  enable  the  (the  software 

engineering  groon  aiid  oilier  s''^ware- 
related  groups)  /  detenrii'e  ttic.  ..uccess 
in  achieving  the  qur’.*  <»<■•  <5  for  the 
software  products,  v’  -  1,  4.1) 

Measurements  to  determine  the  status  of 
the  .!.,„ware  quclitv  management  activities. 
(L4-31,  Ml) 

Measurements  .  6'  software  quality 

anagement.  {L4-i0,  Cl,2) 

Measurements  u,'*':!  -o  quantify  the 
characteristic*  •'f  s^'f'ware  produet  quality. 

(I  4.77,  A3.  2) 

fi  4meric  value  >  for  •  ’  iracteristic  of 

software  product  quaiii) .  (L4-27,  A3,  3) 

Plans  to  achieve  the  software  quality  goals. 
(L4-29,  A4,  1.3^ 

Project's  quantitative  quality  goals  for  the 
software  products.  (L4-27,  A3) 

Project's  software  quality  plan.  (L4-23, 

Al) 

[Refer  to  Standards  for  additional 

information  regarding  the  project's 
software  quality  plan.] 

Quality  goals  applicable  to  the  software 
task.  (L4-29,  A4,  1.2) 

Quality  goals  for  each  software  life-cycle 
stage.  (L4-28,  A3,  5) 

Quality  goals  for  the  software  products. 
(U-20.  Cl,  3) 

Quality  of  the  project's  software  products 
(L4-29,  A4) 

Continued  on  next  page 
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SQM  Process  -  Outputs,  Continued 


Outputs, 

continued 


The  table  below  li.»ts  ‘.he  recommended  outputs  produced  by  the  software  quality 
management  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Quality  of  the  software  work  products  of 
each  software  life-cycle  stage.  (L4-29,  A4, 
2) 

Responsibilities  for  soltware  quality 
management.  (L4-21,  Cl,  4) 

Results  (of  SQA  group  reviews  and/or 
audits  of  the  activities  and  work  products 
for  software  quality  management).  (L4-32, 
V3) 

Results  of  the  quality  tradeoff  decisions 
made  when  software  quality  goals  conflict. 
(L4-30,  A4,  5.3) 
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SQM  Process  -  Exit  Criteria 


Output'based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  management  process. 


T 

Output 

Search  Criteria/ 

Notes 

References 

Capability  of  the 
project’s  defined 
software  process  to 
satisfy  the  software 
quality  goals 

□  is  assessed.  (L4-24,  Al,  3) 

□  is  documented.  (L4-24,  Al,  3) 

Characteristics  of 
product  quality  (that 
describe  how  well  the 
software  product  will 
perform  or  how  well 
it  can  be  developed 
and  maintained) 

are  identified.  (L4-27,  A3,  I) 

Criteria  to  enable  the 
groups  (the  software 
engineering  group 
and  other  software- 
related  groups)  to 
determine  their 
success  in  achieving 
the  quality  goals  for 
the  software  products 

are  established.  (L4-2 1 ,  C 1 ,  4. 1 ) 

Measurements  (to 
determine  the  status 
of  the  software 
quality  managem'int 
activities) 

□  are  made..  (L4-31,  Ml) 

□  are  used.  (L4-31,M1) 

Measurements  used 
for  software  quality 
management 

□  are  defined.  (L4-20,  Cl,2) 

□  are  collected.  (L4-20,  Cl,  2) 

□  are  based  on  the  project's  defined 
software  process.  (14-20,  Cl,  2) 

Measurements  used 
to  quantify  the 
characteristics  of 
software  product 
quality 

are  identified.  (L4-27,  A3,  2) 

Continued  on  next  page 
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SQM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CI^M  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Numeric  values  (for 
each  characteristic  of 
software  product 
quality) 

□  are  measurable.  (L4-27,  A3,  3) 

□  are  based  on  the  required  and 
desired  values.  (L4-27,  A3,  3) 

□  are  selected  as  quality  goals  for 
the  product.  (L4-27,  A3,  3) 

Plans  to  achieve  the 
software  quality  goals 

are  identified  by  the  team 
performing  the  software  task.  (L4- 
29,  A4,  1.3) 

Project's  quantitative 
quality  goals  for  the 
software  products 

□  are  defined.  (L4-27,  A3) 

□  are  monitored  throughout  the 
software  life  cycle.  (L4-27,  A3) 

□  are  revised  throughout  the 
software  life  cycle.  (14-27,  A3) 

Continued  on  next  page 
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SQM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  management  process,  continued  from  the  previous 
page. 


~T 

Output 

State 

References 

Project's  software 
quality  plan 

□  is  developed  according  to  a 
documented  procedure.  (L4-23, 
Al) 

□  is  maintained  according  to  a 
documented  procedure.  (L4-23, 
Al) 

□  satisfies  the  quality  plans  of  the 
organization,  as  appropriate. 
(L4-24,  Al,  4) 

□  is  based  on  plans  for  previous  or 
current  projects  in  the 
organization,  as  appropriate. 
(L4-24,  Al,  5) 

□  is  updated  at  the  start  of  the 
project.  (L4-24,  Al,  6) 

□  is  updated  at  major  project 
milestones.  (L4-24,  Al,  6) 

□  is  updated  whenever  the  allocated 
requirements  change 
significantly.  (L4-24,  Al,  6) 

□  undergoes  peer  review.  (L4-24, 
Al,7) 

□  is  reviewed  by  afi’ected  groups 
and  individuals.  (L4-24,  Al,  8) 

□  is  reviewed  by  senior 
management.  (L4-25,  Al,  9) 

□  is  managed  and  controlled.  (L4- 
25,  Al,  10) 

□  is  available  to  all  affected  groups 
and  individuals.  (L4-25,  Al,  11) 

Continued  on  next  page 
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SQM  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  software  quality  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Quality  goals 
applicable  to  the 
software  task 

are  determined  by  the  team 
performing  the  software  task.  (L4- 
29,  A4,  1.2) 

Quality  goals  for 
each  software  life- 
cycle  stage 

□  are  defined.  (M-28,  A3,  5) 

□  are  documented.  (L4-28,  A3,  5) 

Quality  goals  for  the 
software  products 

□  are  defined  by  the  project.  (L4- 
20,  Cl.  3) 

□  are  documented  in  the  project’s 
software  quality  plan.  (L4-28, 

A3,  4) 

Quality  of  the 
project's  software 
products 

□  is  measured  on  an  event-driven 
basis.  (L4-29,  A4) 

□  is  analyzed  on  an  event-driven 
basis.  (L4-29,  A4) 

□  is  compared  to  the  products’ 
quantitative  quality  goals  on  an 
event-driven  basis.  (L4-29,  A4) 

Quality  of  the 
software  work 
products  of  each 
software  life-cycle 
stage 

are  measured.  (L4-29,  A4,  2) 

Responsibilities  for 
software  quality 
management 

□  are  defined.  (L4-21,Ci,4) 

□  are  assigned  to  the  software 
engineering  group  and  other 
software-related  groups.  (L4- 
21,  Cl.  4) 

Results  (of  SQA 
group  reviews  and/or 
audits  of  the  actWities 
and  work  products 
for  software  quality 
management) 

are  reported.  (L4-32,  V3) 
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SQM  Process  -  Exit  Criteria,  continued 


GenerL>I  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  quality  management  process. 


V 

Condition 

References 

The  project's  software  quality  management  activities  support 
the  organization's  commitment  to  improve  the  quality  of  the 
software  products.  (L4-20,  Cl,  1) 

The  project  defines  the  quality  goals  for  the  software 
products  and  monitors  its  progress  towards  them.  (L4-20, 

Cl,  3) 

An  understanding  of  the  software  quality  needs  of  the 
organization,  customer,  and  end  users  is  developed  as 
appropriate.  (L4-23,  Al,  1) 

The  software  quality  needs  and  priorities  of  the  organization, 
customer,  and  end  user  are  traceable  to  the  system 
requirements  allocated  to  software  and  the  software  quality 
goals.  (L4-23,  Al,2) 

The  project's  software  quality  plan  is  the  basis  for  the 
project's  activities  for  software  quality  management.  (L4-25, 
A2) 

Quality  goals  for  the  software  products  and  software  life- 
cycle  stages  are  revised  as  understanding  of  the  products  and 
understanding  of  the  organization's,  customer's,  and  end 
users'  needs  evolve.  (L4-29,  A3,  6) 

The  software  tasks  are  planned  and  performed  to  address  the 
project's  software  quality  goals.  At  the  beginning  of  a 
software  task,  the  team  performing  the  task:  (L4-29,  A4, 1) 

□  Reviews  the  quality  goals  for  the  software  product.  (L4- 
29,  A4,  1.1) 

□  Reviews  changes  made  to  the  process  to  meet  the 
software  quality  goals.  (L4-29,  A4,  1.4) 

The  quality  measurements  are  analyzed  and  compared  to  the 
software  quality  goals  to  determine  whether  the  quality  goals 
are  satisfied.  (L4-30,  A4,  3) 

Appropriate  actions,  consistent  with  the  software  quality 
plan,  are  taken  to  bring  the  quality  measures  of  the  products 
in  line  with  the  software  quality  goals.  (L4-30,  A4,  4) 

Continued  on  next  page 
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SQM  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  software  quality  management  process,  continued  from  the  previous 
page. 


T 

Condition 

References 

When  it  is  determined  that  the  software  quality  goals  conflict 
(that  is,  one  goal  cannot  be  achieved  without  compromising 
another  goal),  actions  are  taken  to  resolve  the  conflict.  (L4* 
30,  A4,  5) 

□  The  cost  for  achieving  the  software  quality  goals  is 
analyzed. 

□  Alternative  software  quality  goals  are  considered  in  light 
of  long-term  business  strategies  as  well  as  short-term 
priorities. 

□  The  customer  and  end  users  participate  in  quality 
tradeoff  decisions,  as  appropriate. 

□  The  software  work  products  and  plans  are  revised,  as 
appropriate,  to  reflect  the  results  of  the  tradeoffs. 

The  software  project's  quantitative  quality  goals  for  the 
products  are  allocated  appropriately  tc  the  subcontractors 
delivering  software  products  to  the  project.  (L4-30,  A5) 

The  activities  for  software  quality  management  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L4-31,  VI) 

The  activities  for  software  quality  management  are  reviewed 
with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis.  (L4-31,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  quality 
management  and  reports  the  results.  (L4-32,  V3) 
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SQM  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  software  quality 
management  process. 


V 

Review  or  Audit 

Review 

Participants 

References 

Specialty  engineers  in  areas  such  as  safety 
and  reliability  are  available  to  help  set  the 
software  quality  goals  and  review  progress 
towards  the  goals.  (L4-21,  Abl,  1) 

Specialty 
engineers  in 
areas  such  as 
safety  and 
reliability 

The  software  quality  plan  undergoes  peer 
review.  (L4-24,  Al,  7) 

Not  specified  in 
CMM 

The  software  quality  plan  is  reviewed  by 
affected  groups  and  individuals.  (LA-24, 
Al,8) 

Affected 
groups  and 
individuals 

Senior  management  reviews  the  software 
quality  plans.  (14-25,  Al,  9) 

Senior 

management 

The  software  tasks  are  planned  and 
performed  to  address  the  project’s  software 
quality  goals.  At  the  beginning  of  a 
software  task,  the  team  performing  the 
task:  (L4-29,  A4,  1) 

□  Reviews  the  quality  goals  for  the 
software  product.  (L4-29,  A4,  1.1) 

□  Reviews  changes  made  to  the  process  to 
meet  the  software  quality  goals.  (L4- 
29,  A4,  1.4) 

Team 

performing  the 
software  task 

The  activities  for  software  quality 
management  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L4-31, 
VI) 

Senior 

management 

The  activities  for  software  quality 
management  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L4-31,  V2) 

Project 

manager 

The  software  quality  assurance  gioup 
reviews  and/or  audits  the  activities  and  work 
products  for  software  quality  management 
and  reports  the  results.  (L4-32,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify: 

□  The  preparation  of  the  project’s 
software  quality  plan. 

□  The  process  for  establishing  and 
tracking  the  software  quality  goals. 

Software 

quality 

assurance 

group 
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SQM  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  software  quality  management  process. 


V 

Work  Products  Managed  and  Controlled 

References 

Project’s  software  quality  plan.  (L4-25,  Al,  10) 
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SQM  Process  -  Measurements 


Measurements  The  table  below  lists  the  measurements  recommended  for  the  software  quality 
management  process. 


D 

Measurements 

References 

1 

Measurements  used  for  software  quality  management  based 
on  the  project's  defined  software  process.  (L4-20,  Cl,  2) 

■ 

Software  quality.  (L4-26,  A2,  1) 

i 

Software  product  quality.  (L4-26,  A2,  4) 

1 

Measurements  used  to  quantify  the  characteristics  of 
software  product  quality.  (L4-27,  A3,  2) 

Quality  of  the  project’s  software  products.  (L4-29,  A4) 

1 

Quality  of  the  software  work  products  of  each  software  life- 
cycle  stage.  (L4-29,  A4,  4) 

1 

Measurements  to  determine  the  status  of  the  software  quality 
management  activities.  (L4-31,  Ml) 

Examples  of  measurements  include:, 

□  The  cost  of  poor  quality  (based  on  known  quality 
measurements  to  whatever  degree  of  accuracy  they  can 
be  collected). 

□  The  costs  for  achieving  the  quality  goals. 
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SQM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  software  quality  management  process  activities  that  are 
recommended  to  be  performed  according  to  a  documented  procedure. 


T 

Documented  Procedure(s) 

References 

The  project's  software  quality  plan  is  developed  and 
maintained  according  to  a  documented  procedure.  (L4-23, 
Al) 

[Refer  to  Level  4  Procedure  Checklists  for  additional 
information.] 
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SQM  Process  >  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  software  quality 
management  process. 


T 

Training 

References 

The  individuals  implementing  and  supporting  software 
quality  management  receive  required  training  to  perform 
their  activities.  (LA-22,  Ab2) 

The  members  of  the  software  engineering  group  and  other 
software*reiated  groups  receive  required  training  in 
software  quality  management.  (L4-22,  Ab3) 
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SQM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  software  quality  management 
process. 


Tools 

References 

Tools  to  support  predicting,  measuring,  tracking,  and 
analyzing  software  quality.  (L4-21,  Abl,  2) 

Examples  of  support  tools  include: 

□  data  collection  toots, 

□  database  systems, 

□  spreadsheet  programs, 

□  software  life-cycle  simulators, 

□  quantitative  analysis  tools,  and 

□  code  audit  tools. 
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Level  4  Procedure  Checklists 
Overview 


Introduction 


Purpose 


In  this  section 


This  section  describes  all  the  explicit  documented  procedures  in  the  Capability 
Maturity  Model  for  maturity  level  4. 


The  purpose  of  the  procedure  checklists  is  to  provide: 

•  Guidance  in  identifying  which  procedures  are  recommended  by  the  CMM  at 
level  4, 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  procedures  to 
determine  if  those  procedures  are  consistent  with  the  CMM  at  level  4. 

•  Information  that  can  be  used  to  develop  software  procedures  that  are  consistent 
with  the  CMM  at  level  4. 


This  section  covers  the  following  documented  procedures: 


CMM  Level  4  Procedures 

See  Page 

Quantitative  process  management  procedures 

L4-Procedures-2 

Software  quality  management  procedure 

L4-Procedures-6 
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Quantitative  Process  Management  (QPM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  quantitative 
process  management  process. 


Documented  Procedures 

References 

The  software  project’s  plan  for  quantitative  process 
management  is  developed  according  to  a  documented 
procedure.  (L4-6,  AI) 

This  procedure  typically  specifies  that: 

□  The  quantitative  process  management  plan  is  based  on: 

□  the  organization's  strategic  goals  for  product  quality, 
productivity,  and  product  development  cycle  time; 

□  the  organization's  measurement  program; 

□  the  organization’s  standard  software  process; 

□  the  project's  goals  for  the  software  product's  quality, 
productivity,  and  product  development  cycle  time; 

□  the  measured  performance  of  other  projects'  defined 
software  processes;  and 

□  the  description  of  the  project's  defined  software 
process. 

□  The  plan  undergoes  peer  review. 

□  The  plan  is  reviewed  by  the  group  responsible  for  the 
organization's  software  process  activities  (e.g.,  the 
software  engineering  process  group). 

□  The  plan  is  managed  and  controlled. 

Continued  on  next  page 
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QPM  Procedures,  Continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  quantitative 
process  management  process,  continued  from  the  previous  page. 


V 

Documented  Procedures 

References 

The  measurement  data  used  to  control  the  project's  defined 

software  process  quantitatively  are  collected  according  to  a 

documented  procedure.  (L4-9,  A4) 

This  procedure  typically  specifies  that: 

□  The  measurement  data  collected  support  the 
organization's  and  the  software  project's  measurement 
goals  and  objectives. 

□  The  specific  measurement  data  to  be  collected,  their 
precise  definitions,  the  intended  use  and  analysis  of  each 
measurement,  and  the  process  control  points  at  which 
they  will  be  collected  are  defined. 

□  The  measurements  are  chosen  from  the  entire  software 
life  cycle  (e.g.,  both  the  development  and  post- 
development  stages). 

□  The  measurements  cover  the  properties  of  the  key 
software  process  activities  and  major  software  work 
products. 

□  The  measurement  data  that  relate  to  the  organization’s 
standard  software  process  are  uniformly  collected  across 
the  software  projects. 

□  The  measurements  to  be  controlled  are  a  natural  result 
of  the  software  activities  where  possible. 

□  The  measurements  are  selected  to  support  predefined 
analysis  activities. 

□  The  validity  of  the  measurement  data  is  independently 
assessed. 

□  The  collected  measurement  data  are  stored  in  the 
organization’s  software  process  database  as  appropriate. 

Continued  on  next  page 
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QPM  Procedures,  Continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  quantitative 
procesi,  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

References 

The  project's  defined  software  process  is  analyzed  and 
brought  under  quantitative  control  according  to  a 
documented  procedure.  (L4-10,  A5) 

This  procedure  typically  specifies  that: 

□  The  specific  data  analysis  activities  are  predefined. 

□  Measurement  data  on  the  process  activities  throughout 
the  project's  defined  software  process  are  identified, 
collected,  and  analyzed. 

□  The  selected  measurements  appropriately  characterize 
the  process  they  represent. 

□  The  expected  values  for  mean  and  variance  are  specified 
for  each  measurement. 

□  The  acceptable  limits  for  each  measurement  are  defined 
and  the  project's  process  performance  baseline  is 
established. 

□  The  actual  values  of  each  measurement  are  compared  to 
the  expected  values  of  the  mean  and  variance. 

□  Adjustments  are  made  to  bring  the  actual  process 
performance  in  line  with  the  defined  acceptable  limits,  as 
appropriate. 

□  When  the  project's  defined  software  process  is  controlled 
quantitatively,  baselines  are  established  for: 

□  the  definition  of  the  measurements, 

□  the  actual  measurement  data,  and 

□  the  acceptable  limits  for  the  measurements. 

□  The  process  performance  baseline  for  the  software 
project  is  managed  and  controlled. 

Continued  on  next  page 
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QPM  Procedures,  Continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  quantitative 
process  management  process,  continued  from  the  previous  page. 


Documented  Procedures 

References 

The  process  capability  baseline  for  the  organization’s 

standard  software  process  is  established  and  maintained 

according  to  a  documented  procedure.  (L4-13,  A7) 

This  procedure  typically  specifies  that: 

□  The  project's  software  process  data,  as  summarized  in  its 
process  performance  baseline,  are  recorded  in  the 
organization's  software  process  database. 

□  The  process  performance  baseline  for  each  project's 
defined  software  process  is  incorporated,  as  appropriate, 
into  the  process  capability  baseline  for  the  organization’s 
standard  software  process. 

□  The  process  capability  baseline  for  the  organization's 
standard  software  process  is  documented. 

□  Process  capability  trends  for  the  organization's  standard 
software  process  are  examined  to  predict  likely  problems 
or  opportunities  for  improvements. 

□  The  process  capability  baseline  for  the  organization’s 
standard  software  process  is  managed  and  controlled. 

□  When  a  software  project  that  is  substantially  different 
from  past  projects  is  undertaken,  a  new  process 
performance  baseline  is  established  for  that  project  as 
part  of  tailoring  the  organization’s  standard  software 
process. 

□  Changes  to  the  organization's  standard  software  process 
are  tracked  and  analyzed  to  assess  their  effects  on  the 
process  capability  baseline. 
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Software  Quality  Management  (SQM)  Procedure 


Documented 

procedure 


The  table  below  lists  the  recommended  documented  procedure  for  the  software 
quality  management  process. 


Documented  Procedure 

References 

The  project's  software  quality  plan  is  developed  and 

maintained  according  to  a  documented  procedure.  (L4-23, 
Al) 

This  procedure  typically  specifies  that: 

□  An  understanding  of  the  software  quality  needs  of  the 
organization,  customer,  and  end  users  is  developed  as 
appropriate. 

□  The  software  quality  needs  and  priorities  of  the 
organization,  customer,  and  end  user  are  traceable  to  the 
system  requirements  allocated  to  software  and  the 
software  quality  goals. 

□  The  capability  of  the  project’s  defined  software  process 
to  satisfy  the  software  quality  goals  is  assessed  and 
documented. 

□  The  software  quality  plan  satisfies  the  quality  plans  of 
the  organization,  as  appropriate. 

□  The  software  quality  plan  is  based  on  plans  for  previous 
or  current  projects  in  the  organization,  as  appropriate. 

□  The  software  quality  plan  is  updated  at  the  start  of  the 
project,  at  major  project  milestones,  and  whenever  the 
allocated  requirements  change  significantly. 

□  The  software  quality  plan  undergoes  peer  review. 

□  The  software  quality  plan  is  reviewed  by  affected  groups 
and  individuals. 

□  Senior  management  reviews  the  software  quality  plans. 

□  The  software  quality  plan  is  managed  and  controlled. 

□  The  software  quality  plan  is  available  to  all  affected 
groups  and  individuals. 
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Level  4  Summary 
Overview 


Section  purpose 


Section 

overview 


The  purpose  of  this  section  is  to  provide  checklists  that  provide  a  summarj  of  the 
managed  level  (level  4).  This  section  contains  three  perspectives  of  a  CMM  level. 

•  Key  process  area  (KPA)  specific  information: 

KPA  purpose 

KPA  goals 

•  Operational  framework  information  (from  a  maturity  level  viewpoint): 

Policies 

Standards 

Process  descriptions 

Procedures 

Training 

Tools 

•  Other  key  process  information  (from  a  maturity  level  viewpoint): 

Reviews  and  audits 

Work  products  managed  and  controlled 
Measurements 


This  section  contains  the  following  topics. 


Topic 

Page 

Level  4  -  KPA  Purposes 

L4-Summai'y-2 

Level  4  -  KPA  Goals 

L4-Summary-3 

Level  4  -  Policies 

L4-Summary-4 

Level  4  -  Standards 

L4-Summary-5 

Level  4  -  Process  Descriptions 

L4-Summary-6 

Level  4  -  Procedures 

L4-Summary-7 

Level  4  -  Training 

L4-Summary-8 

Level  4  -  Tools 

L4-Summary-9 

Level  4  -  Reviews  and  Audits 

L4-Summary-10 

Level  4  -  Work  Products  Managed  and  Controlled 

L4-Summary-12 

Level  4  -  Measurements 

L4-Summary-13 

CMU/SEI-94<HB-1 


L4-Summary-1 


Level  4  -  KPA  Purposes 


Level  4  KPA 
purposes 


The  following  table  describes  the  purpose  of  each  key  process  area  in  the  CMM  at 
level  4. 


KPA 

Purpose  of  KPAs  at  Level  4 

QPM 

The  purpose  of  Quantitative  Process  Management  is  to  control  the 
process  performance  of  the  software  project  quantitatively.  Software 
process  performance  represents  the  actual  results  achieved  from 
following  a  software  process.  (L4-1) 

I 

SQM 

The  purpose  of  Software  Quality  Management  is  to  develop  a 
quantitative  understanding  of  the  quality  of  the  project's  software 
products  and  achieve  specific  quality  goals.  (L4-19) 
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Level  4  -  KPA  Goals 


Level  4  KPA 
goals 


The  following  table  lists  the  goals  that  are  described  in  the  CMM  for  each  key  process 
area  at  level  4. 


KPA 

CMM  Got>ls  at  Level  4 

References 

QPM 

The  quantitative  process  management  activities  are 
planned.  (L4-2,  Gl) 

QPM 

The  process  performance  of  the  project's  defined 
software  process  is  controlled  quantitatively.  (L4-2, 

G2) 

QPM 

The  process  capability  of  the  organization's  standard 
software  process  is  known  in  quantitative  terms.  (L4- 
2,  G3) 

SQM 

The  project's  software  quality  management  activities 
are  planned.  (L4-20,  Gl) 

SQM 

Measurable  goals  for  software  product  quality  and 
their  priorities  are  defined.  (L4-20,  G2) 

SQM 

Actual  progress  toward  achieving  the  quality  goals  for 
the  software  products  is  quantified  and  managed.  (L4- 
20,  G3) 
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Level  4  -  Policies 


Level  4  policies  The  following  table  lists  the  recommended  policies  in  the  CMM  at  level  4. 


References 


KPA 

Description 

QPM 

Written  organizational  policy  for  measuring  and 
quantitatively  controlling  the  performance  of  the 
project's  defined  software  process.  (L4-2,  Cl) 

QPM  I 

i 

1 

Written  policy  for  analyzing  the  process  capability  of 
the  organization's  standard  software  process.  (L4-3, 

C2) 

SQM 

1 

Written  organizational  policy  for  managing  software 
quality.  (L4-20,  Cl) 
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Level  4  -  Standards 


Level  4 
standards 


Reference 


The  CMM  recommends  the  contents  of  the  following  work  products  at  level  4; 


KPA 

Standards  at  Level  4 

References 

QPM 

Projects’  quantitative  process  management  plan.  (L4- 
7,A2) 

SQM 

Project's  software  quality  plan.  (L4-25,  A2) 

Refer  tc  the  Level  4  Standards  Checklists  for  additional  information  regarding  the 
CP”  ent  of  each  standard. 
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Level  4  -  Process  Descriptions 


QPM  process 
description 


SQM  process 
description 


Quantitative  Process  Management  involves  establishing  goals  for  the  performance  of 
the  project's  defined  software  process,  which  is  descnbed  in  the  Integrated  Software 
Management  key  process  area,  taking  measurements  of  the  process  performance, 
analyzing  these  measurements,  and  making  adjustments  to  maintain  process 
performance  within  acceptable  limits.  When  the  process  performance  is  stabilized 
within  acceptable  limits,  the  project's  defined  software  process,  the  associated 
measurements,  and  the  acceptable  limits  for  the  measurements  are  established  as  a 
baseline  and  used  to  control  process  performance  quantitatively. 

The  organization  collects  process  performance  data  from  the  software  projects  and 
uses  these  data  to  characterize  the  process  capability  (i.e.,  the  process  performance  a 
new  project  can  expect  to  attain)  of  the  organization's  standard  software  process, 
which  is  described  in  the  Organization  Process  Definition  key  process  area.  Process 
capability  describes  the  range  of  expected  results  from  following  a  software  process 
(i.e.,  the  most  likely  outcomes  that  are  expected  from  the  next  software  project  the 
organization  undertakes).  These  process  capability  data  are,  in  turn,  used  by  the 
software  projects  to  establish  and  revise  their  process  performance  goals  and  to 
analyze  the  performance  of  the  projects'  defined  software  processes.  (L4-1 ) 


Software  Quality  Management  involves  defining  quality  goals  for  the  software 
products,  establishing  plans  to  achieve  these  goals,  and  monitoring  and  adjusting  the 
software  plans,  software  work  products,  activities,  and  quality  goals  to  satisfy  the 
needs  and  desires  of  the  customer  and  end  user  for  high  quality  products. 

The  practices  of  Software  Quality  Management  build  on  the  practices  of  the  Integrated 
Software  Management  and  Software  Product  Engineering  key  process  areas,  which 
establish  and  implement  the  project's  defined  software  process,  and  the  Quantitative 
Process  Management  key  process  area,  which  establishes  a  quantitative  understanding 
of  the  ability  of  the  project's  defined  software  process  to  achieve  the  desired  results. 

Quantitative  goals  are  established  for  the  software  products  based  on  the  needs  of  the 
organization,  the  customer,  and  the  end  users.  So  that  these  goals  may  be  achieved, 
the  organization  establishes  strategies  and  plans,  and  the  project  specifically  adjusts  its 
defined  software  process,  to  accomplish  the  quality  goals.  (L4-19) 
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Level  4  -  Procedures 


Level  4 
procedures 


The  table  below  lists  the  activities  that  are  recommended  to  be  performed  according 
to  a  documented  procedure  in  the  CMM  at  level  4.  Refer  to  the  Level  4  Procedure 
Checklists  for  additional  information  regarding  the  content  of  each  documented 
procedure. 


rr 

KPA 

Documented  Procedures 

References 

QPM 

The  software  project’s  plan  for  quantitative  process 
management  is  developed  according  to  a  documented 
procedure.  (L4-6,  Al) 

QPM 

The  measurement  data  used  to  control  the  project's 
defined  software  process  quantitatively  are  collected 
according  to  a  documented  procedure.  (L4-9,  A4) 

QPM 

The  project's  defined  software  process  is  analyzed  and 
brought  under  quantitative  control  according  to  a 
documented  procedure.  (L4-10,  A5) 

QPM 

The  process  capability  baseline  for  the  organization’s 
standard  software  process  is  established  and 
maintained  according  to  a  documented  procedure. 
(L4-13,  A7) 

SQM 

The  project's  software  quality  plan  is  developed  and 
maintained  according  to  a  documented  procedure. 
(U-23.AI) 
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Level  4  -  Training 


Level  4  training  The  table  below  lists  the  training  recommended  in  the  CMM  at  level  4. 


KPA 

Training 

QPM 

The  individuals  implementing  or  supporting 
quantitative  process  management  receive  required 
training  to  perform  these  activities.  (L4-6,  Ab4') 

QPM 

The  members  of  the  software  engineering  group  and 
other  software-related  groups  receive  orientation  on 
the  goals  and  value  of  quantitative  process 
management.  (L4-6,  Ab5) 

SQM 

I 

The  individuals  implementing  and  supporting 
software  quality  management  receive  required 
training  to  perform  their  activities.  (L4-22,  Ab2) 

SQM 

The  members  of  the  software  engineering  group 
and  other  software-related  groups  receive  required 
training  in  software  quality  management.  (L4-  .  2, 

Ab3) 

References 
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Level  4  -  Tools 


Level  4  tools  The  table  below  lists  the  tools  recommended  in  the  CNiM  for  level  4. 


~T 

KPA 

Tools 

References 

QPM 

Tools  to  support  quantitative  process  management, 
(L4-5,  Ab2,  3) 

QPM 

Organization’s  software  process  database.  (L4-10,  A4, 
9) 

SQM 

Tools  to  support  predicting,  measuring,  tracking,  and 
analyzing  software  quality.  (L4-21,  Abl,  2) 
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Level  4  -  Reviews  and  Audits 


Level  4  reviews 
and  audits 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  4. 


T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

QPM 

The  project’s  quantitative  process 
management  plan  undergoes  peer 
review.  (L4-7,  Al,2) 

Not  specified 
in  the  CMM 

QPM 

The  project’s  quantitative  process 
management  plan  is  reviewed  by  the 

group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  the  software 
engineering  process  group).  (L4-7, 
Al,3) 

Group 

responsible  for 
the 

organization's 
software 
process 
activities  (e.g., 
the  software 
engineering 
process  group) 

QPM 

The  results  of  the  data  analysis  are 
reviewed  with  those  affected  by  the 
data  before  they  are  reported  to 
anyone  else.  (L4-12,  A6, 1) 

Not  specified 
in  the  CMM 

QPM 

The  activities  for  quantitative 
process  management  are  reviewed 
with  senior  management  on  a 
periodic  basis.  (L4-15,  VI) 

Senior 

management 

QPM 

The  software  project’s  activities  for 
quantitative  process  management  are 
reviewed  with  the  project  manager 
on  both  a  periodic  and  event-driven 
basis.  (U-16,V2) 

Project 

manager 

QPM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
quantitative  process  management 
and  reports  the  results.  (L4-16,  V3) 

Software 

quality 

assurance 

group 

SQM 

Specialty  engineers  in  areas  such 
as  safety  and  reliability  are 
available  to  help  set  the  software 
quality  goals  and  review  progress 
towards  the  goals.  (L4-21,  Abl,  1) 

Specialty 
engineers  in 
areas  such  as 
safety  and 
reliability 

SQM 

The  software  quality  plan  undergoes 
peer  review.  (L4-24,  Al,  7) 

Not  specifled 
in  CMM 

SQM 

The  software  quality  plan  is 
reviewed  by  affected  groups  and 
individuals.  (L4-24,  AI,8) 

Affected 
groups  and 
individuals 

Continued  on  next  page 
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Level  4  -  Reviews  and  Audits,  continued 


Level  4  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  4, 
continued  from  the  previous  page. 


~T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

SQM 

Senior  management  reviews  the 
software  quality  plans.  (L4-25,  A1 , 

9) 

Senior 

management 

SQM 

The  software  tasks  are  planned  and 
performed  to  address  the  project's 
software  quality  goals.  At  the 
beginning  of  a  software  task,  the 
team  performing  the  task:  (L4-29, 
A4,l) 

□  Reviews  the  quality  goals  for  the 
software  product.  0A-29,  A4, 
1.1) 

□  Reviews  changes  made  to  the 
process  to  meet  the  software 
quality  goals.  (L4-29,  A4,  1 .4) 

Team 

performing  the 
software  task 

SQM 

The  activities  for  software  quality 
management  are  reviewed  with 
senior  management  on  a  penodic 
basis.  (L4-31,V1) 

Senior 

management 

SQM 

The  activities  for  software  quality 
management  are  reviewed  with  the 
project  manager  on  both  a  periodic 
and  event-driven  basis.  (L4-31,  V2) 

Project 

manager 

SQM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
software  quality  management  and 
reports  the  results.  (L4-32,  V3) 

Software 

quality 

assurance 

group 
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Level  4  <•  Work  Products  Managed  and  Controlled 


Level  4  work 
products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  in  the  CMM  at  level  4. 


T 

KPA 

Work  Products  Managed  and  Controlled 

References 

QPM 

Project’s  quantitative  process  management  plan.  (L4- 
7,A1,4) 

QPM 

Process  performance  baseline  for  the  software  project. 
(L4-12,  A5,9) 

'1 

QPM 

Process  capability  baseline  for  the  organization's 
standard  software  process.  (L4-14,  A7, 5) 

SQM 

Software  quality  plan.  (L4-25,  Al,  10) 
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Level  4  -  Measurements 


Level  4 
measurements 


The  table  below  describes  the  recommended  measurements  in  the  CMM  at  level  4. 


KPA 

Description 

References 

QPM 

Measurements  to  determine  the  status  of  the  activities 
for  quantitative  process  management.  (L4-15,  Ml) 

SQM 

Measurements  used  for  software  quality  management 
based  on  the  project's  defined  software  process.  (L4- 
20,  Cl,  2) 

SQM 

Software  quality.  (L4-26,  A2, 1) 

SQM 

Software  product  quality.  (L4-26,  A2, 4) 

SQM 

Measurements  used  to  quantify  the  characteristics  of 
software  product  quality.  (L4-27,  A3,  2) 

SQM 

Quality  of  the  project’s  software  products.  (L4-29, 

A4) 

SQM 

Quality  of  the  software  work  products  of  each  software 
life-cycle  stage.  (L4-29,  A4, 4) 

SQM 

Measurements  to  determine  the  status  of  the  software 
quality  management  activities.  (L4-31,  Ml) 
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Chapter  7.  Optimizing  Levei  (Level  5) 
Overview 


Introduction  This  chapter  contains  the  checklists  for  Level  3  of  the  CMM. 
In  this  chapter  This  chapter  contains  the  following  sections: 
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Level  5  Policy  Checklists 
Overview 


Introduction 


Purpose 


Checklist 

description 


In  this  section 


This  section  describes  the  explicit  policies  found  in  the  Capability  Maturity  Model 
at  maturity  level  5. 


The  purpose  of  the  policy  checklists  is  to  provide: 

•  Guidance  in  identifying  which  policies  are  recommended  by  the  CMM  at  level  5. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  policies  to  determine 
if  they  are  consistent  with  the  CMM  at  level  5. 

•  Information  that  can  be  used  to  develop  software  policies  so  that  they  are 
consistent  with  the  CMM  at  ievel  5. 


Each  checklist  contains  two  subsections:  the  KPA  policies  and  the  KPA  goals.  The 
table  below  describes  these  two  subsections  of  a  policy  checklist. 


Subsection 

Description 

Policy  checklist 

This  subsection  contains  criteria  that  the  organizational 
policy  can  be  evaluated  against.  These  criteria  must  be 
addressed  by  organizational  policy  to  be  consistent  with  the 
CMM. 

Policy  goals 

This  subsection  is  a  reminder  to  policy  designers  and 
evaluators  to  keep  in  mind  the  KPA  goals  when  developing 
the  policies  for  each  KPA.  The  goals  can  be  thought  of  as 
the  results  of  implementing  an  effective  policy. 

This  section  covers  the  following  policies: 


Policies 

See  Page 

Defect  prevention  policies 

L5-Policy-2 

Technology  change  management  policy 

L5-Policy-3 

Process  change  management  policy 

L5-Policy-4 
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Defect  Prevention  (DP)  Policies 


DP  policy  1 
checklist 


DP  policy  2 
checklist 


DP  policy 
goals 


The  organization  follows  a  written  policy  for  defect  prevention  activities  (L5-2, 
Cl).  This  policy  typically  specifies  that: 


Description 

References 

Long-term  plans  and  commitments  are  established  for 
funding,  staffing,  and  other  resources  for  defect  prevention. 
(L5-2,C1,  1) 

The  resources  needed  are  allocated  for  the  defect  prevention 
activities.  (L5-2,  Cl,  2) 

Defect  prevention  activities  are  implemented  across  the 
organization  to  improve  the  software  processes  and 
products.  (L5-2,  Cl,  3) 

The  results  of  the  defect  prevention  activities  are  reviewed  to 
ensure  the  effectiveness  of  those  activities.  {L5-2,  Cl,  4) 

Management  and  technical  actions  identified  as  a  result  of 
the  defect  prevention  activities  are  addressed.  (L5-2,  Cl,  5) 

The  project  follows  a  written  organizational  policy  for  defect  prevention  activities 
(L5-2,  C2).  This  policy  typically  specifies  that: 


Description 

References 

Defect  prevention  activities  are  included  in  each  project's 
software  development  plan.  (L5-3,  C2,  1) 

The  resources  needed  are  allocated  for  the  defect  prevention 
activities.  (L5-3,  C2,  2) 

Project  management  and  technical  actions  identified  as  a 
result  of  the  defect  prevention  activities  are  addressed.  (L5- 
3,  C2,  3) 

Implementation  of  effective  defect  prevention  policies  has  the  following  results: 


Results  of  Effectively  Implementing  DP  Policies 

References 

Defect  prevention  activities  are  planned.  (L5-2,  Gl) 

Common  causes  of  defects  are  sought  out  and  identified. 
(L5-2,  G2) 

Common  causes  of  defects  are  prioritized  and  systematically 
eliminated.  (L5-2,  G3) 

L5.Policy-2 
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Technology  Change  Management  (TCM)  Policy 


TCM  policy 
checklist 


TCM  policy 
goals 


The  organization  follows  a  written  policy  for  improving  its  technology  capability 
(L5-18,  Cl).  This  policy  typically  specifies  that: 


T 

Description 

References 

Objectives  for  technology  change  management  are 
established  and  documented.  (L5-18,  Cl,  1) 

A  documented  plan  addresses  the  objectives  for  technology 
change  management.  (L5-19,  Cl,  2) 

Implementation  of  an  effective  technology  change  management  policy  has  the 
following  results: 


Results  of  Effectively  Implementing  TCM  Policy 

References 

Incorporation  of  technology  changes  are  plarmed.  (L5-18, 
Gl) 

New  technologies  are  evaluated  to  determine  their  effect  on 
quality  and  productivity.  (L5-18,  G2) 

Appropriate  new  technologies  are  transferred  into  normal 
practice  across  the  organization.  (L5-18,  G'3) 
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Process  Change  Management  (PCM)  Policy 


PCM  policy 
checklist 


PCM  policy 
goals 


The  organization  follows  a  written  policy  for  implementing  software  process 
improvements  (L5-32,  Cl).  This  policy  typically  specifies  that: 


T 

Description 

References 

The  organization  has  quantitative,  measurable  goals  for 
software  process  improvement  and  tracks  performance 
against  these  goals.  (L5-32,  Cl,  1) 

The  organization’s  process  improvements  are  directed 
toward  improving  product  quiity,  increasing  productivity, 
and  decreasing  the  cycle  time  for  product  development. 
(L5-32,  Cl,  2) 

All  of  the  organization's  staff  and  managers  are  expected  to 
participate  in  improving  the  software  processes.  (L5-32,  Cl, 
3) 

Implementation  of  an  effective  process  change  management  policy  has  the 
following  results: 


T 

Results  of  Effectively  Implementing  PCM  Policy 

References 

Continuous  process  improvement  is  planned.  (L5-32,  Gl) 

Participation  in  the  organization’s  software  process 
improvement  activities  is  organization  wide.  0^5-32,  G2) 

The  organization's  standard  software  process  and  the 
projects'  defined  software  processes  are  improved 
continuously.  (L5-32,  G3) 

L5-Policy-4 
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Level  5  Standards  Checklists 
Overview 


Introduction 


Definition 


Purpose 


What  the 
standards 
checklists  are 
not 


In  this  section 


This  section  describes  the  recommended  content  of  selected  work  products  in  the 
CMM  at  mamrity  level  5. 


A  standard  checklist  describes  the  content  of  a  work  product  as  recommended  by 
the  CMM. 


The  purpose  of  the  standards  checklists  is  to  provide: 

•  Guidance  in  identifying  the  contents  of  standard  work  products  that  are 
recommended  by  the  CMM  at  level  5. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  sof  ware  standards  to 
detennine  if  they  are  consistent  with  the  CMM  at  level  5. 

•  Information  that  can  be  used  to  develop  software  standards  that  are  consistent 
with  the  CMM  at  level  5. 


The  standards  checklists  contain  only  what  is  recommended  by  the  CMM,  and  are 
not  complete  standards  in  themselves.  For  example,  the  standard  for  the  software 
development  plan  (SDP)  contains  only  content  recommended  by  the  CMM.  Other 
sources  for  the  content  of  a  SDP  should  also  be  considered,  such  as  ANSI/ICEE  Std 
1058.1-1987,  DOD-STD-2167,  DI-MCCR-8(X)30,  etc. 


This  section  covers  the  follovidng  standards: 


Standard 

KPA 

See  Page 

Project  plan  for  defect  prevention  activities 

DP 

L5-Standards-2 

Plan  for  technology  change  management 

TCM 

L5-Standards-3 

Plan  for  pilot  efforts  to  improve  technology 

TCM 

L5-Standards-4 

Software  process  improvement  plan 

PCM 

L5-Standards-5 
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L5-Standards-1 


Project  Plan  for  Defect  Prevention  Activities 


Standard  The  following  lable  contains  what  the  CMM  describes  as  the  recommended  content 

checklist  of  a  project  plan  for  defect  prevention  activities.  This  plan: 


~T 

Recommended  Content 

Identifies  the  defect  prevention  activities  (e.g.,  task  kick-off  and  causal 
analysis  meetings)  that  will  be  held.  (L5-5,  Al,  I) 

Specifies  the  schedule  of  defect  prevention  activities.  (L5-5,  Al,  2) 

_J 

Covers  the  assigned  responsibilities  and  resources  required,  including  staff 
and  tools.  (L5-5,  Al,  3) 

L5-Standards-2 
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Plan  for  Technology  Change  Management 


standard  The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 

checklist  of  a  plan  for  technology  change  management.  This  plan: 


~T 

Recommended  Content 

Covers  the  assigned  responsibilities  and  resources  required,  including  staff 
and  tools.  (L5-23,  Al,  1) 

Defines  the  long-term  technical  strategy  for  automating  and  improving  the 
organization's  standard  software  process  and  enhancing  the  organization’s 
maricet  position.  (L5-23,  Al,  2) 

Identifies  the  procedures  to  be  followed  in  performing  the  organization's 
technology  change  management  activities.  (L5-23,  Al,  3) 

_ I 

Describes  the  approach  for  introducing  new  technologies  to  address  specific 

needs  of  the  organization  and  projects.  (L5-24,  Al,  4) 

□  Process  areas  that  are  potential  areas  for  technology  changes  are 
identified. 

□  Approaches  for  identifying  opportunities  for  technology  changes  are 
identified. 

□  The  specific  planned  or  candidate  technologies  are  identified, 

□  Where  appropriate,  the  life  span  for  the  planned  technologies  is 
estimated,  from  introduction  to  replacement. 

□  The  make/buy  tradeoff  studies  are  documented. 

□  Approaches  for  assessing  unproven  candidate  technologies  are  defined. 

□  The  acquisition  and  installation  procedures  are  defined. 

□  The  initial  training,  continuing  training,  and  consultation  support  are 
defined. 
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L5-Standards-3 


Plan  for  Pilot  Efforts  to  Improve  Technology 


Standard 

checklist 


The  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  plan  for  pilot  efforts  to  improve  technology: 


Recommended  Content 

Objectives  for  the  pilot  effort.  (L5-27,  A6,  2.1) 

Evaluation  criteria  for  the  pilot  effort.  (L5-27,  A6,  2.1) 

Activities  for  the  pilot  effort.  {L5-27,  A6,  2.1) 

L5-Standards-4 
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Software  Process  Improvement  Plan 


Standard 

checklist 


Tiie  following  table  contains  what  the  CMM  describes  as  the  recommended  content 
of  a  software  process  improvement  plan: 


Recommended  Content 

The  resources  required,  including  staff  and  tools.  (L5-38,  A4,  1) 

The  highest  priority  process  areas  for  improvement.  (L5-38,  A4,  2) 

Measurable  short-term  and  long-term  goals  for  software  process 
performance  and  improvement.  (L5-38,  A4,  3) 

Teams  and  their  assignments  for  addressing  im.provements  for  specific 
process  areas.  (L5-38,  A4,  4) 

The  procedures  for:  (L5-38,  A4,  5) 

□  the  senior  managers  overseeing  the  software  process  improvement 
activities; 

□  the  software  managers  planning  and  coordinating  the  software  process 
improvement  activities; 

□  individuals  and  teams  identifying,  evaluating,  and  introducing 
appropriate  software  process  improvements;  and 

□  the  teams  developing  software  process  improvements  for  assigned 
process  areas. 

The  administrative  and  support  plans  requited  to  maintain  continuous 

process  improvement.  (L5-38,  A4,  6) 

□  Appropriate  administrative  procedures  are  included  to  encourage 
participation  in  and  facilitate  the  software  process  improvement 
activities. 

□  Administrative  personnel  are  included  in  oversight  and  review  of  the 
software  process  improvement  activities. 

□  The  roles  and  contributions  of  employees  to  continuous  process 
improvement  are  recognized. 
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Level  5  Process  Checklists 
Overview 


Section  purpose 


In  this  section 


The  puipose  of  the  process  checklists  is  to  provide: 

•  Guidance  in  identifying  which  processes  are  required  by  the  CMM  at  level  5. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  processes  to 
determine  if  they  are  consistent  with  the  CMM  at  level  5. 

•  Information  that  can  be  used  to  develop  software  processes  that  are  consistent 
with  the  CMM  at  level  5. 


This  section  contains  checklists  for  the  following  key  process  areas: 


Key  Process  Area 

See  Page 

Defect  Prevention 

L5-Process-3 

Technology  Change  Management 

L5-Process-35 

Process  Change  Management 

L5 -Process-77 
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Defect  Prevention  (DP)  Process 
DP  Process  -  Overview 


DP  process 
purpose 


DP  process 
description 


The  puipose  of  Defect  Prevention  is  to  identify  the  cause  of  defects  and  prevent 
them  from  recurring.  (L5-1) 


Defect  Prevention  involves  analyzing  defects  that  were  encountered  in  the  past  and 
taking  specific  actions  to  prevent  the  occurrence  of  those  types  of  defects  in  the 
future.  The  defects  may  have  been  identified  on  other  projects  as  well  as  in  earlier 
stages  or  tasks  of  the  current  project.  Defect  prevention  activities  are  also  one 
mechanism  for  spreading  lessons  learned  between  projects. 

Trends  are  analyzed  to  track  the  types  of  defects  that  have  been  encountered  and 
to  identify  defects  that  are  likely  to  recur.  Based  on  an  understanding  of  the 
project's  defined  software  process  and  how  it  is  implemented  (as  described  in  the 
Integrated  Software  Management  and  Software  Product  Engineering  key  process 
areas),  the  root  causes  of  the  defects  and  the  implications  of  the  defects  for  future 
activities  are  determined. 

Both  the  project  and  the  organization  take  specific  actions  to  prevent  recurrence  of 
the  defects.  Some  of  the  organizational  actions  may  be  handled  as  described  in  the 
Process  Qiange  Management  key  process  area.  (L5-1) 


Continued  on  next  page 
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DP  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L5-Process-5 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L5-Process-9 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L5-Process-10 

Activities 

Description  of  the  activities  of  the 
process. 

L5-Process-12 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L5-Process-16 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L5-Process-20 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L5-Process-27 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L5 -Process-29 

Measurements 

Description  of  process  measurements. 

L5-Process-30 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L5-Process-31 

Training 

List  of  training. 

L5-Process-32 

Tools 

List  of  tools. 

L5-Process-33 

L5-Process-4 
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DP  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
defect  prevention  process. 


Roles 

Activities  Participated  in... 

Reference 

Causal 
analysis 
meeting  leader 

The  (causal  analysis  meetings)  are  led  by  a 
person  trained  in  conducting  causal 
analysis  meetings.  (L5-7,  A3, 2) 

Project 

manager 

The  software  project's  activities  for  defect 
prevention  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L5-15,  V2) 

Senior 

management 

The  organization's  activities  for  defect 
prevention  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L5-14, 
VI) 

Software 

engineering 

group 

or 

Members  of 
the  software 
engineering 
group 

□  Members  of  the  software  engineering 
group  and  other  software-related 
groups  receive  required  training  to 
perform  their  defect  prevention 
activities.  (L5-4,  Ab4) 

□  Members  of  the  software  engineering 
group  and  software-related  groups 
receive  feedback  on  the  status  and 
results  of  the  organization’s  and 
project's  defect  prevention  activities  on 
a  periodic  basis.  (L5-12,  A8) 

Software 

engineering 

manager 

The  software  engineering  managers  and 
technical  staff  are  trained  for  theft  defect 
prevention  roles.  (L5-15,  V3,  1) 

Software- 
related  groups 

or 

Members  of 
the  software- 
related  groups 

□  Members  of  the  software  engineering 
group  and  other  software-related 
groups  receive  required  training  to 
perform  their  defect  p-  /ention 
activities.  (L5-4,  AtK" 

□  Members  of  the  software  engineering 
group  and  software-related  groups 
receive  feedback  on  the  status  and 
results  of  the  organization's  and 
project's  defect  prevention  activities  on 
a  periodic  basis.  (L5-12,  A8) 

Continued  on  next  page 
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DP  Process  -  Roles,  continued 


Rolesj 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
defect  prevention  process,  continued  from  the  previous  page. 


~T 

Role 

Activities  Participated  in... 

Reference 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  defect  prevention  and  reports 
the  results.  (L5-15,  V3) 

Submitters  of 
the  action 
proposals 

Each  of  the  teams  assigned  to  coordinate 
defect  prevention  activities  document  their 
rationale  for  decisions  and  provide  the 
decision  and  the  rationale  to  the  submitters 
of  the  action  proposals.  (L5-9,  A4, 6) 

Team 

performing  the 
software  task 

or 

Members  of 
the  team 
performing  the 
software  task 

□  At  the  beginning  of  a  software  task,  the 
members  of  the  team  performing  the 
task  meet  to  prepare  for  the  activities  of 
that  task  and  the  related  defect 
prevention  activities.  (L5-6,  A2) 

□  Each  team  that  performs  a  software 
task  conducts  causal  analysis  meetings. 
(L5-7,  A3,  1) 

Teams 
assigned  to 
coordinate 
defect 
prevention 
activities  (the 
organization* 
level  team  or 
the  teams  for 
each  software 
project) 

□  Each  of  the  teams  assigned  to 
coordinate  defect  prevention  activities 
meets  on  a  periodic  basis  to  review  and 
coordinate  implementation  of  action 
proposals  from  the  causal  analysis 
meetings.  (L5-8,  A4) 

□  The  teams: 

□  Review  the  output  from  the  causal 
analysis  meetings  and  select  action 
proposals  that  will  be  addressed. 

□  Review  action  proposals  that  have 
been  assigned  to  them  by  other 
teams  coordinating  defect 
prevention  activities  in  the 
organization  and  select  action 
proposals  that  will  be  addressed. 

□  Review  actions  taken  by  the  other 
teams  in  the  organization  to  assess 
whether  these  actions  can  be 
applied  to  their  activities  and 
processes. 

Role  '.ontinues  on  next  page 

Continued  on  next  page 
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DP  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
defect  prevention  process,  continued  from  the  previous  page. 


T 

Role 

Activities  Participated  in... 

Reference 

Teams 
assigned  to 
coordinate 
defect 
prevention 
activities  (the 
organization- 
level  team  or 
the  teams  for 
each  software 
project), 
continued 

□  The  teams:  (L5-8,  A4) 

□  Perform  a  preliminary  analysis  of 
the  action  proposals  and  set  their 
priorities. 

□  Reassign  action  proposals  to  teams 
at  another  level  in  the  organization, 
as  appropriate. 

□  Document  their  rationale  for 
decisions  and  provide  the  decision 
and  the  rationale  to  the  submitters 
of  the  action  proposals. 

□  Assign  responsibility  for 
implementing  the  action  items 
resulting  from  the  action  proposals. 

Q  Implementation  of  the  action 
items  includes  making 
immediate  changes  to  the 
activities  that  are  within  the 
purview  of  the  team  and 
arranging  for  other  changes. 

□  Members  of  the  team  usually 
iraplemeiji  the  action  items,  but, 
in  some  cases,  the  team  can 
arrange  for  someone  else  to 
implement  an  action  item. 

□  Review  results  of  defect  prevention 
experiments  and  take  actions  to 
incorporate  the  results  of  successful 
experiments  into  the  rest  of  the 
project  or  organization,  as 
appropri.'’te. 

□  Track  the  status  of  the  action 
proposals  and  action  items. 

Role  continues  on  next  page 

Continued  on  next  page 
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DP  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
defect  prevention  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Teams 
assigned  to 
coordinate 
defect 
prevention 
activities  (the 
organization- 
level  team  or 
the  teams  for 
each  software 
project), 
continued 

□  The  teams:  (L5-8,  A4) 

□  Document  software  process 
improvement  proposals  for  the 
organization's  standard  software 
process  and  the  projects'  defined 
software  processes  as  appropriate. 

□  Review  and  verify  completed  action 
items  before  they  are  closed. 

□  Ensure  that  significant  efforts  and 
successes  in  preventing  defects  are 
recognized. 

□  Defect  prevention  data  are  documented 
and  tracked  across  the  teams 
coordinating  defect  prevention 
activities.  (L5-11,A5) 

Teams  at 
another  level 
in  the 

organization 

The  teams  assigned  to  coordinate  defect 
prevention  activities  reassign  action 
proposals  (from  the  causal  analysis 
meetings)  to  teams  at  another  level  in  the 
organization,  as  appropriate.  (L5-9,  A4, 5) 

Technical  staff 

The  software  engineering  managers  and 
technical  staff  are  trained  for  their  defect 
prevention  roles.  (L5-15,  V3,  1) 

L5-Process-8 
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DP  Process  -  Entry  Criteria 


Input-based 
entry  criteria 


General  entry 
criteria 


There  are  no  input-based  entry  criteria  in  the  defect  prevention  process. 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  defect  prevention  process. 


V 

Condition 

References 

The  organization  follows  a  written  policy  for  defect 
prevention  activities  (L5-2,  Cl). 

[Refer  to  Level  5  Policies  for  additional  information 
regarding  DP  policy.] 

An  organization-level  team  to  coordinate  defect  prevention 
activities  exists.  (L5-3,  Abl) 

The  organization-level  team  to  coordinate  defect 
prevention  activities  is  either  part  of  the  group  responsible 
for  the  organization's  software  process  activities  (e.g., 
software  engineering  process  group)  or  its  activities  are 
closely  coordinated  with  that  group.  (L5-3,  Abl,  1) 

A  team  to  coordinate  defect  prevention  activities  for  the 
software  project  exists.  (L5-3,  Ab2) 

This  team  is  closely  tied  to  the  team  responsible  for 
developing  and  maintaining  the  project's  defined  software 
process.  (L5-3,  Ab2, 1) 

Adequate  resources  and  ftmding  are  provided  for  defect 
prevention  activities  at  the  project  and  organization  levels. 
(L5-4,  Ab3) 

Defect  prevention  activities  are  planned  into  each  person’s 
responsibilities,  as  appropriate.  (L5-4,  Ab3,  1) 

Management  participation  in  the  defect  prevention  activities 
is  planned.  (L5-4,  Ab3, 2) 

Each  software  project  is  represented  on  the  team 
coordinating  defect  prevention  activities  for  the 
organization,  as  appropriate.  (L5-4,  Ab3,  3) 

Tools  to  support  defect  prevention  activities  are  made 
available.  (L5-4,  Ab3,  4) 

Members  of  the  software  engineering  group  and  other 
software-related  groups  receive  required  training  to 
perform  their  defect  prevention  activities.  (L5-4,  Ab4) 
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DP  Process  -  Inputs 


Inputs 


The  table  below  lists  the  recommended  inputs  to  the  defect  pre^'ention  process. 


Input 

Org.  Input 

References 

Action  items  resulting  from  the  action 
proposals  (from  the  causal  analysis 
meetings).  (L5-9,  A4,  7) 

Action  proposals  from  the  causal  analysis 
meetings.  (L5-8,  A4) 

Categories  of  root  causes.  (L5-7,  A3, 4) 

Changes  to  software  methods.  (L5-6,  A2, 

1) 

Completed  action  items  (resulting  from 
action  proposals  from  the  causal  analysis 
meetings).  (L5-10,  A4,  11) 

Inputs  required  and  available  for  the 
(software)  task.  (L5-6,  A2.  2) 

List  of  errors  that  are  commonly  made  or 
introduced  during  the  current  stage.  (L5- 
6,  A2, 6) 

Methods  to  be  used  to  evaluate  the  outputs. 
(L5-6,  A2.  4) 

Methods  to  be  used  to  verify  adherence  to 
the  software  process,  (L5-6,  A2,  5) 

Organization's  standard  software  process. 
(L5-10,  A4,  10) 

Output  from  the  causal  analysis  meetings. 
(L5-9.  A4.  1) 

Outputs  to  be  produced  with  examples,  if 
available.  (L5-6,  A2,  3) 

Projects'  defined  software  processes.  (L5- 
3,  Ab2, 1) 

Recommended  preventive  actions  (for 
errors  that  are  commonly  made  or 
introduced  during  the  current  stage).  (L5- 
6,  A2,  6) 

Results  of  defect  prevention  experiments. 
(L5-10,  A4,  8) 

Results  of  successful  (defect  prevention) 
experiments.  (L5-10,  A4,  8) 

Software  methods.  (L5-6,  A2, 1) 

Software  product  quality  goals  for  the 
software  project.  (L5-7,  A2,  9) 

Continued  on  next  page 
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DP  Process  -  Inputs,  Continued 


Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  defect  prevention  process, 
continued  from  the  previous  page. 


T 

Input 

Org.  Input 

References 

Software  product  quality  goals  for  the 
software  task.  (L5-7,  A2, 9) 

Software  products.  (L5-2.  Cl,  3) 

Task  schedule.  (L5-6,  A2,  8) 

Team  assignments.  (L5-6,  A2, 7) 

Work  products  for  defect  prevention.  (L5- 
15,  V3) 
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DP  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  defect  prevention  process. 


~T 

Activities 

References 

The  software  project  develops  and  maintains  a  plan  for  its 
defect  prevention  activities.  (L5-5,  Al) 

□  This  plan  undergoes  peer  review.  (L5-5,  Al,4) 

At  the  beginning  of  a  software  task,  the  members  of  the 

team  performing  the  task  meet  to  prepare  for  the  activities 

of  that  task  and  the  related  defect  prevention  activities.  (L5- 

6.  A2) 

These  kick-off  meetings  cover: 

□  The  software  process,  standards,  procedures,  methods, 
and  tools  applicable  to  the  task,  with  an  emphasis  on 
recent  changes. 

□  The  inputs  required  and  available  for  the  task. 

□  The  outputs  to  be  produced  with  examples,  if  available. 

□  The  methods  to  be  used  to  evaluate  the  outputs. 

□  The  methods  to  be  used  to  verify  adherence  to  the 
software  process. 

□  A  list  of  errors  that  are  commonly  made  or  introduced 
during  the  current  stage  and  recommended  preventive 
actions  for  these  errors. 

□  The  team  assignments. 

□  The  task  schedule. 

□  The  software  product  quality  goals  for  the  task  and 
software  project. 

Causal  analysis  meetings  are  conducted  according  to  a 
documented  procedure.  (L5-7,  A3) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

Continued  on  next  page 


L5-Process-l2 


CMU/SEI-94-HB-1 


DP  Process  -  Activities,  continued 


Activities,  The  table  below  lists  the  recommended  activities  for  the  defect  prevention  process, 
continued  continued  from  the  previous  page. 


T 

Activities 

References 

Each  of  the  teams  assigned  to  coordinate  defect  prevention 
activities  meets  on  a  periodic  basis  to  review  and  coordinate 
implementation  of  action  proposals  from  the  causal  analysis 
meetings.  (L5-8,  A4) 

□  The  teams: 

□  Review  the  output  from  the  causal  analysis  meetings 
and  select  action  proposals  that  will  be  addressed. 

□  Review  action  proposals  that  have  been  assigned  to 
them  by  otlier  teams  coordinating  defect  prevention 
activities  in  the  organization  and  select  action 
proposals  that  will  be  addressed. 

□  Review  actions  taken  by  the  other  teams  in  the 
organization  to  assess  whether  these  actions  can  be 
applied  to  their  activiti '-s  and  prov'.esses. 

□  Perforai  a  preliminary  analysis  of  the  action 
proposals  and  set  their  priorities. 

□  Reassign  action  proposals  to  teams  at  another  level 
in  the  organization,  as  appropriate. 

□  Document  their  rationale  for  decisions  and  provide 
the  decision  and  the  rationale  to  the  submitters  of  the 
action  proposals. 

□  Assign  responsibility  for  implementing  the  action 
items  resulting  from  the  action  proposals. 

□  Implementation  of  the  action  items  includes 
making  immediate  changes  to  the  activities  that 
are  within  the  purview  of  the  team  and  arranging 
for  other  changes. 

□  Members  of  the  team  usually  implement  the 
action  items,  but,  in  some  cases,  the  team  can 
arrange  for  someone  else  to  implement  an  action 
item. 

□  Review  results  of  defect  prevention  experiments  and 
take  actions  to  incorporate  the  results  of  successful 
experiments  into  the  rest  of  the  project  or 
organization,  as  appropriate. 

□  Track  the  status  of  the  action  proposals  and  action 
items. 

Activity  continued  on  next  page 

Continued  on  next  page 
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DP  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  defect  prevention  process, 
continued  from  the  previous  page. 


Activities 

References 

Activity  continued  from  previous  page 

□  Review  results  of  defect  prevention  experiments  and 
t^e  actions  to  incoiporate  the  results  of  successful 
experiments  into  the  rest  of  the  project  or 
organization,  as  appropriate. 

□  Track  the  status  of  the  action  proposals  and  action 
items. 

□  Document  software  process  improvement  proposals 
for  the  organization's  standard  software  process  and 
the  projects'  defined  software  processes  as 
appropriate. 

□  Review  and  verify  completed  action  items  before 
they  are  closed. 

□  Ensure  that  significant  efforts  and  successes  in 
preventing  defects  are  recognized. 

Defect  prevention  data  are  documented  and  tracked  across 
the  teams  coordinating  defect  prevention  activities.  (L5-1 1, 
A5) 

□  Action  proposals  identified  in  causal  analysis  meetings 
are  documented. 

□  Action  items  resulting  from  action  proposals  are 
documented. 

□  The  defect  prevention  data  are  managed  and  controlled. 

Revisions  to  the  organization's  standard  software  process 
resulting  from  defect  prevention  actions  are  incorporateo 
according  to  a  documented  procedure.  (L5-12,  A6) 

Revisions  to  the  project's  defined  software  process  resulting 
from  defect  prevention  actions  are  incorporated  according 
to  a  documented  procedure.  (L5-12,  A7) 

ivicmbers  of  the  software  engineering  group  and  software- 
related  groups  receive  feedback  on  the  status  and  results  of 
the  organization's  and  project's  defect  prevention  activities 
on  a  periodic  basis.  (L5-12,  A8) 

Measurements  are  made  and  used  to  determine  the  status  of 
the  defect  prevention  activities.  (L5-13,  Ml) 

The  organization's  activities  for  defect  prevention  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L5- 
14,  VI) 

Continued  on  next  page 
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DP  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  defect  prevention  process, 
continued  from  the  previous  page. 


Activities 

References 

The  software  project's  activities  for  defect  prevention  are 
reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis.  (L5-15,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  defect  prevention  and 
reports  the  results.  (L5-15,  V3) 
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DP  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  defect  prevention 
process. 


~T 

Output 

Org.  Output 

References 

Action  items  resulting  from  action 
proposals.  (L5-1I,  A5,  2) 

Action  proposals  (from  the  causal  analysis 
meetings).  (L5-9,  A4,  1) 

Actual  cost  of  completed  defect  prevention 
activities.  (L5-15,  VI,6) 

Commitments  for  funding,  staffing,  and 
other  resources  for  defect  prevention.  (L5- 
2,  Cl.l) 

Common  causes  of  defects.  (L5-8,  A3,  6) 

Decision(s)  (for  action  proposals).  (L5-9, 
A4.  6) 

Defect  prevention  data.  (L5-11,  A5) 

Defects.  (L5-7,  A3,  3) 

Feedback  on  the  status  and  results  of  the 
organization's  and  project's  defect 
prevention  activities.  (L5-12,  A8) 

Frequency  distribution  of  actions  in  the 
major  action  categories.  (L5-14,  VI,  2) 

Frequency  disuibution  of  defects  in  the 
major  defect  categories.  (L5-13,  A8,  2) 

Inputs  required  and  available  for  the 
(software)  task.  (L5-6,  A2, 2) 

List  of  errors  that  are  commonly  made  or 
introduced  during  the  current  stage.  (L5- 
6,  A2,  6) 

Long-term  plans  for  funding,  staffing,  and 
other  resources  for  defect  prevention.  (L5- 
2.C1. 1) 

Management  actions  identified  as  a  result 
of  the  defect  prevention  activities.  (L5-2, 
Cl.  5) 

Measurements  (to  determine  the  status  of 
defect  prevention  activities).  (L5-13,  Ml) 

Methods  to  be  used  to  evaluate  the  outputs. 
(L5-6.  A2,  4) 

Methods  to  be  used  to  verify  adherence  to 
the  software  process.  (L5-6,  A2,  5) 

Continued  on  next  page 
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DP  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  defect  prevention 
process,  continued  from  the  previous  page. 


T 

Output 

Org.  Output 

References 

Number  of  defects  uncovered.  (L5-7,  A3, 
1.2) 

Outputs  to  be  produced  with  examples,  if 
available.  ^5-6,  A2,  3) 

Plan  for  (the  software  project’s)  defect 
prevention  activities.  (L5-5,  Al) 

[Refer  to  Level  5  Standards  for  additional 
information  regarding  this  plan.] 

Priorities  (for  action  proposals).  (L5-9, 

A4, 4) 

Project  management  actions  identified  as  a 
result  of  the  defect  prevention  activities. 
(L5-3,  C2,  3) 

Project  technical  actions  identified  as  a 
result  of  the  defect  prevention  activities. 
(L5.3,  C2,  3) 

Project’s  software  development  plan.  (L5- 
3,  C2, 1) 

Projected  cost  of  planned  defect  prevention 
activities.  (L5-15,  VI,  6) 

Proposed  actions  to  prevent  the  future 
occurrence  of  identified  defects  and  similar 
defects.  (L5-8,  A3,  5) 

Rationale  for  decisions  (about 
implementing  action  proposals  from  the 
causal  analysis  meetings).  (L5-9,  A4,  6) 

Recommended  preventive  actions  (for 
errors  that  are  commonly  made  or 
introduced  during  the  current  stage  of  a 
software  task).  (L5-6,  A2,  6) 

Results  (of  the  SQA  group  reviews  and/or 
audits  of  the  activities  and  work  products 
for  defect  prevention).  (L5-15,  V3) 

Results  of  the  (causal  analysis)  meeting. 
(L5-8.  A3,  7) 

Results  of  the  defect  prevention  activities. 
(L5-2,  Cl.  4) 

Continued  on  next  page 
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DP  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  defect  prevention 
process,  continued  from  the  previous  page. 


T 

Output 

Org.  Output 

References 

Revisions  to  the  organization's  standard 
software  process  resulting  from  defect 
prevention  actions.  (L5-12,  A6) 

Revisions  to  the  project's  defined  software 
process  resulting  from  defect  pievention 
actions.  (L5-12.  A7) 

Root  causes  (of  defects).  (L5-7,  A3,  3) 

Schedule  of  defect  prevention  activities. 
(L5-5,  Al,  2) 

Significant  innovations  to  address  the 
major  defect  categories.  (L5-13,  A8,  3) 

Software  methods.  (L5-6,  A2,  1) 

Software  process  improvement  proposals 
for  the  organization's  standard  software 
process.  ^5-10,  A4,  10) 

Software  process  improvement  proposals 
for  the  projects'  defined  software  processes. 
(L5-10,  A4,  10) 

Software  product  quality  goals  for  the 
software  project.  (L5-7,  A2,  9) 

Software  product  quality  goals  for  the  task. 
(L5-7,  A2,  9) 

Software  products.  (L5-7,  A3,  1.3) 

Summary  of  the  effectiveness  of  and 
savings  attributable  to  the  defect  prevention 
activities.  (L5-15,  VI,  5) 

Summary  of  the  major  action  categories. 
(L5-14,  VI,  2) 

Summary  of  the  major  defect  categories. 
(L5-13,  A8,  1) 

Summar)-  status  of  the  action  proposals 
and  action  items.  (L5-13,  A8,  4) 

Summary  status  of  the  proposed,  open,  and 
completed  action  items.  (L5-15,  VI,  4) 

Task  schedule.  (L5-6,  A2,  8) 

Continued  on  next  page 
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DP  Process  -  Outputs,  continued 


Outputs,  The  table  below  lists  the  recommended  outputs  produced  by  the  defect  prevention 

continued  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Team  assignments.  (L5-6,  A2,  7) 

Technical  actions  identified  as  a  result  of 
the  defect  prevention  activities.  (L5-2,  Cl, 
5) 

—  —  -1 
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DP  Process  -  Exit  Criteria 


Output-based  The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
exit  criteria  to  exit  the  defect  prevention  process. 


T 

Output 

State 

References 

Action  items 
resulting  from  action 
proposals 

are  documented.  (L5-11,  A5,  2) 

Action  proposals 
(from  the  causal 
analysis  meetings) 

are  selected.  (L5-9,  A4,  1) 

Changes  to  software 
methods 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2,  1) 

Commitments  for 
funding,  staffing,  and 
other  resources  for 
defect  prevention 

are  established.  (L5-2,  Cl,  1) 

Common  causes  of 
defects 

□  are  identified.  (L5-8,  A3,  6) 

□  are  documented.  (L5-8,  A3,  6) 

Decision(s)  (for 
action  proposals) 

are  provided  to  the  submitters  of  the 
action  proposals.  (L5-9,  A4, 6) 

Defect  prevention 
data 

□  are  documented.  (L5-11,  A5) 

□  are  tracked  across  the  teams 
coordinating  defect  prevention 
activities.  (L5-11,A5) 

□  are  managed  and  controlled. 
(L5-11.  A5,  3) 

Defects 

□  are  identified.  (L5-7,  A3,  3) 

□  are  analyzed  to  determine  their 
root  causes.  (L5-7,  A3,  3) 

□  are  assigned  to  categories  of  root 
causes.  (L5-7,  A3,  4) 

Continued  on  next  page 
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DP  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  defect  prevention  process,  continued  from  the  previous  page. 


T 

Output 

State 

References 

Feedback  on  the 
status  and  results  of 
the  organization's 
and  project's  defect 
prevention  activities 

□  is  received  by  members  of  the 
software  engineering  group  on  a 
periodic  basis.  (L5-12,  A8) 

□  is  received  by  members  of  the 
software-related  groups  on  a 
periodic  basis.  (L5-12,  A8) 

□  provides  (L5-12,  A8): 

□  A  summary  of  the  major 
defect  categories. 

□  The  frequency  distribution 
of  defects  in  the  major  defect 
categories. 

□  Significant  innc:’ations  and 
actions  taken  to  address  the 
major  defect  categories. 

□  A  summary  status  of  the 
action  proposals  and  action 
items. 

Inputs  required  and 
available  for  the 
(software)  task 

arc  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2,  2) 

List  of  errors  that  are 
commonly  made  or 
introduced  during 
the  current  stage 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2,  6) 

Long-term  plans  for 
funding,  staffing,  and 
other  resources  for 
defect  prevention 

arc  established.  (L5-2,  Cl,  1) 

Management  actions 
identified  as  a  result 
of  the  defect 
prevention  activities 

arc  addressed.  (L5-2,  Cl,  5) 

_ 1 

Measurements  (to 
determine  the  status 
of  the  defect 
prevention  activities) 

□  arc  made.  (L5-13,  Ml) 

□  arc  used.  (L5-13,  Ml) 

Continued  on  next  page 
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DP  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  defect  prevention  process,  continued  from  the  previous  page. 


~T 

Output 

State 

References 

Methods  to  evaluate 
the  outputs  (of  a 
software  task) 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2,  4) 

Methods  to  verify 
adherence  to  the 
software  process 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2.  5) 

Outputs  to  be 
produced  with 
examples,  if  available 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6.  A2,  3) 

Plan  for  (the  software 
project’s)  defect 
prevention  activities 

□  is  developed  by  the  software 
project.  (L5-5,  Al) 

□  is  maintained  by  the  software 
project.  (L5-5,  Al) 

□  undergoes  peer  review.  (L5-5, 
Al,4) 

Priorities  (for  action 
proposals) 

are  set.  (L5-9,  A4,  4) 

Project  management 
actions  identified  as  a 
result  of  the  defect 
prevention  activities 

are  addressed.  (L5-3,  C2,  3) 

Project  technical 
actions  identified  as  a 
result  of  the  defect 
prevention  activities 

are  addressed.  (L5-3,  C2,  3) 

Project's  software 
development  plan 

includes  defect  prevention  activities. 
(L5-3,  C2,  1) 

Proposed  actions  to 
prevent  the  future 
occurrence  of 
identified  defects  and 
similar  defects 

□  are  developed.  (L5-8,  A3,  5) 

□  are  documented.  (L5-8,  A3,  5) 

Rationale  for 
decisions  (about 
implementing  action 
proposals  from 
causal  analysis 
meetings) 

□  are  documented.  (L5-9,  A4,  6) 

□  are  provided  to  the  submitters  of 
the  action  proposals.  (L5-9,  A4, 
6) 

Continued  on  next  page 
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DP  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  defect  prevention  process,  continued  from  the  previous  page. 


T 

Output 

State 

References 

Recommended 
preventive  actions 
(for  errors  that  are 
commonly  made  or 
introduced  during 
the  current  stage  of  a 
software  task) 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2,  6) 

Results  (of  the  SQA 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  defect 
prevention) 

are  reported.  (L5-15,  V3) 

Results  of  the  (causal 
analysis)  meeting 

are  recorded  for  use  by  the 
organization  and  other  projects. 

(L5-8.  A3,  7) 

Results  of  the  defect 
prevention  activities 

are  reviewed  to  ensure  the 
effectiveness  of  those  activities.  (L5- 
2.  Cl.  4) 

Revisions  to  the 
organization's 
standard  software 
process  resulting 
from  defect 
prevention  actions 

are  incoiporated  according  to  a 
documented  procedure.  (L5-12,  A6) 

Revisions  to  the 
project's  defined 
software  process 
resulting  from  defect 
prevention  actions 

are  incorporated  according  to  a 
documented  procedure.  (L5-12,  A7) 

Root  causes  (of 
defects) 

are  detennined.  (L5-7,  A3,  3) 

Software  methods 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2,  1) 

Software  process 
improvement 
proposals  for  the 
organization’s 
standard  software 
process 

are  documented,  as  appropriate. 
(L5-10,  A4,  10) 

Continued  on  next  page 
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DP  Process  »  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


General  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  tielow 
to  exit  the  detect  prevention  process,  continued  from  the  previous  page. 


0 

Output 

State 

References 

Software  process 
improvement 
proposals  for  the 
projecL'i'  defined 
software  processes 

are  documented,  as  appropriate. 
(L5-10,  A4,  10) 

Software  product 
quality  goals  for  the 
software  project 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6.  A2.  9) 

Software  product 
quality  goals  for  the 
task 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-7.  A2,  9) 

Task  schedule 

is  covered  in  kick-off  i  Tgs  at  the 
beginning  of  a  software  t  ;k  (L5-7, 
A2.  8) 

Team  assignments 

are  covered  in  kick-off  meetings  at 
the  beginning  of  a  software  task. 
(L5-6,  A2,  7) 

t _ 

Technical  actions 
identified  as  a  result 
of  the  defect 
prevention  activities 

are  addressed.  (L5-2,  Cl,  5) 

Tlie  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  defect  preveniion  process. 


Condition 

References 

1 

The  resources  needed  are  allocated  for  the  (organization’s) 
defect  prevention  activities.  (L5-2,  Cl,  2) 

Defect  prevention  activities  are  implemented  across  the 
organization  to  improve  the  software  processes  and 
products.  (L5-2,  Cl,  3) 

The  resources  needed  are  allocated  for  the  (project’s)  defect 
prevention  activities.  (L5-3,  C2,  2) 

At  the  beginning  of  a  software  task,  the  members  of  the 
team  performing  the  task  meet  to  prepare  for  the  activities 
of  that  task  and  ^e  related  defect  prevention  activities.  (L5- 
6,  A2) 

Causal  analysis  meetings  are  conducted  according  to  a 
documented  procedure.  (i-5-7,  A3) 

Continued  on  next  pag( 
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DP  Process  -  Exit  Criteria,  continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  defect  prevention  process,  continued  from  the  previous  page. 


T 

Condition 

References 

Each  of  the  teams  assigned  to  coordinate  defect  prevention 

activities  meets  on  a  periodic  basis  to  review  and  coordinate 

implementation  of  action  proposals  from  the  causal  analysis 

meetings.  (L5-8,  A4) 

The  teams; 

□  Review  the  output  from  the  causal  analysis  meetings  and 
select  action  proposals  that  will  be  addressed.  (L5-9,  A4, 
1) 

□  Review  action  proposals  that  have  been  assigned  to  them 
by  other  teams  coordinating  defect  prevention  activities 
in  the  organization  and  select  action  proposals  that  will 
be  addressed.  (L5-9,  A4,  2) 

□  Review  actions  taken  by  the  other  teams  in  the 
organization  to  assess  whether  these  actions  can  be 
applied  to  their  activities  and  processes.  (L5-9,  A4,  3) 

□  Perform  a  preliminary  analysis  of  the  action  proposals 
and  set  their  priorities.  (L5*9,  A4, 4) 

□  Reassign  action  proposals  to  teams  at  another  level  In 
the  organization,  as  appropriate.  (L5-9,  A4,  5) 

□  Assign  responsibility  for  implementing  the  action  items 
resulting  from  the  action  proposals.  (L5-9,  A4,  7) 

□  Implementation  of  the  aciion  items  includes  making 
immediate  changes  to  the  activities  that  are  within  the 
purview  of  the  team  and  arranging  for  other 
changes.  (L5-10,  A4,  7.1) 

□  Members  of  the  team  usually  implement  the  action 
items,  but,  in  some  cases,  the  teaiii  can  arrange  for 
someone  else  to  implement  an  action  item.  (L5-10, 
A4,  7.2) 

□  Review  results  of  defect  prevention  experiments  and  take 
actions  to  incorporate  the  results  of  successful 
experiments  into  the  rest  of  the  project  or  organization, 
as  appropriate.  (L5-10,  A4,  8) 

□  Track  the  status  of  the  action  proposals  and  action  items. 
(L5-10,  A4,  9) 

□  Review  and  verify  completed  action  items  before  they 
are  closed.  (L5-10,  A4,  11) 

□  Ensure  that  significant  efforts  and  successes  in 
preventing  defects  are  recognized.  (L5-10,  A4,  12) 

Continued  on  next  page 
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DP  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  defect  prevention  process,  continued  from  the  previous  page. 


T 

Condition 

References 

The  organization's  activities  for  defect  prevention  are 
reviewed  with  senior  management  on  a  periodic  basis.  (L5- 
14,  VI) 

The  software  project's  activities  for  defect  prevention  are 
reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis,  (L5-15,  V2) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  defect  prevention  and 
reports  the  results.  (L5-15,  V3) 
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DP  Process  -  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  defect  prevention 
process. 


T 

Review  or  Audit 

Review 

Participants 

References 

The  results  of  the  defect  prevention 
activities  are  reviewed  to  ensure  the 
effectiveness  of  those  activities.  (L5-2,  Cl, 
4) 

Not  specified  in 
the  CMM 

The  (software  project’s  plan  for  defect 
prevention  activities)  undergoes  peer 
review.  (L5-5,  Al,4) 

Not  specified  in 
the  CMM 

Each  of  the  teams  assigned  to  coordinate 
defect  prevention  activities  meets  on  a 
periodic  basis  to  review  and  coordinate 
implementation  of  action  proposals  from 
the  causal  analyst"  meetings.  (L5-8,  A4) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

The  teams  assigned  to  coordinate  defect 
prevention  activities  review  the  output 
from  the  causal  analysis  meetings  and 
select  action  proposals  that  will  be 
addressed.  (L5-9,  A4,  1) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

The  teams  assigned  to  coordinate  defect 
prevention  activities  review  action 
proposals  that  have  been  assigned  to  them 
by  other  teams  coordinating  defect 
prevention  activities  in  the  organization 
and  select  action  proposals  that  will  be 
addressed.  (L5-9,  A4,  2) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

The  teams  assigned  to  coordinate  defect 
prevention  activities  review  actions  taken 
by  the  other  teams  in  the  organization  to 
assess  whether  these  actions  can  be  applied 
to  their  activities  and  processes.  (L5-9,  A4, 
3) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

The  teaw  assigned  to  coordinate  defect 
prevention  activities  review  results  of 
defect  prevention  experiments  and  take 
actions  to  incorporate  the  results  of 
successful  experiments  into  the  rest  of  the 
project  or  organization,  as  appropriate. 
(L5-10,  A4,  8) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

Continued  on  next  page 
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DP  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  defect  prevention 
process,  continued  from  the  previous  page. 


T 

Review  or  Audit 

Review 

Participants 

References 

The  teams  assigned  to  coordinate  defect 
prevention  activities  review  and  verify 
completed  action  items  before  they  are 
closed.  (L5-10,  A4,  11) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

The  organization's  activities  for  defect 
prevention  are  reviewed  with  senior 
management  on  a  periodic  basis.  (L5-14, 
VI) 

Senior 

management 

The  software  project's  activities  for  defect 
prevention  are  reviewed  with  the  project 
manager  on  both  a  periodic  and  event- 
driven  basis.  (L5-15,  V2) 

Project 

manager 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  defect  prevention  and  reports 
the  results.  (L5-15,  V3) 

At  a  minimum,  the  reviews  and/or  audits 
verify  that: 

□  The  software  engineering  managers 
and  technical  staff  are  trained  for  their 
defect  prevention  roles.  (L5-15,  V3,  1) 

□  The  task  kick-off  meetings  and  causal 
analysis  meetings  are  properly 
conducted.  (L5-15,  V3,  2) 

□  The  process  for  reviewing  action 
proposals  and  implementing  action 
items  is  followed.  (LS-V*?,  V3,  3) 

Software 

quality 

assurance 

group 
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DP  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
controlled  during  the  defect  prevention  process. 


Work  Products  Managed  and  Controlled 

References 

Defect  prevention  data.  (L5-11,A5,  3) 
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DP  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  defect  prevention 
process. 


II 

Measurements 

References 

Defect  prevention  data.  (L5-11,A5) 

Measurements  to  determine  the  status  of  the  defect 

prevention  activities.  (L5-13,  Ml) 

Examples  of  measurements  include: 

□  The  costs  of  defect  prevention  activities  (e.g.,  holding 
causal  analysis  meetings  and  implementing  action  items. 

□  The  time  and  cost  for  identifying  the  defects  and 
correcting  them,  compared  to  the  estimated  cost  of  not 
correcting  the  defects. 

□  Profiles  measuring  the  number  of  action  items  proposed, 
open,  and  completed. 

□  The  number  of  defects  injected  in  each  stage, 
cumulatively,  and  over  releases  of  similar  products. 

□  The  number  of  defects. 
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DP  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  for  the  defect  prevention  process  recom.nended 
to  be  performed  according  tc  a  documented  procedure. 


~T 

Documented  Procedure(s) 

References 

Causal  analysis  meetings  are  conducted  according  to  a 
documented  procedure,  (L5-7,  A3) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

Revisions  to  the  organization's  standard  software  process 
resulting  from  defect  prevention  actions  are  incorporated 
according  to  a  documented  procedure.  (L5-12,  A6) 

Revisions  to  the  project's  defined  software  process  resulting 
from  defect  prevention  actions  are  incorporated  according 
to  a  documented  procedure.  (L5-12,  A7) 
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DP  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  defect  prevention  process. 


~T 

Training 

References 

Members  of  the  software  engineering  group  and  other 
software-related  groups  receive  required  training  to 
perform  their  defect  prevention  activities.  (L5-4,  Ab4) 
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DP  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  defect  prevention  process. 


Tools 

References 

Tools  to  support  defect  prevention  activities.  (L5-4,  Ab3,  4) 
Examples  of  support  tools  include: 

□  statistical  analysis  tools,  and 

□  database  systems. 
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Technology  Change  Management  (TCM)  Process 
TCM  Process  -  Overview 


TCM  process 
purpose 


TCM  process 
description 


CMU/SEI-94 


The  purpose  of  Technology  Change  Ma  nagement  is  to  identify  new  technologies 
(i.e.,  tools,  methods,  and  processes)  and  track  them  into  the  organization  in  an 
orderly  manner.  (L5- 17) 


Technology  Change  Management  involves  identifying,  selecting,  and  evaluating 
new  technologies,  and  incorporating  effective  technologies  into  the  organization. 
The  objective  is  to  improve  software  quality,  increase  productivity,  and  decrease  the 
cycle  time  for  product  development. 

The  organization  establishes  a  group  (such  as  a  software  engineering  process 
group  or  a  technology  support  group)  that  works  with  the  software  projects  to 
introduce  and  evaluate  new  technologies  and  manage  changes  to  existing 
technologies.  Particular  emphasis  is  placed  on  technology  changes  that  are  likely 
to  improve  the  capability  of  the  organization’s  standard  software  process  (as 
described  in  the  Organization  Process  Definition  key  process  area). 

By  maintaining  an  awareness  of  software-related  technology  innovations  and 
systematically  evaluating  and  experimenting  with  them,  the  organization  selects 
appropriate  technologies  to  improve  the  quality  of  its  software  and  the  productivity 
of  its  software  activities.  Pilot  efforts  are  performed  to  assess  new  and  unproven 
technologies  before  they  are  incorporated  into  normal  practice.  With  appropriate 
sponsorship  of  the  organization’s  management,  the  selected  technologies  are 
incorporated  into  the  organization’s  standard  software  process  and  current  projects, 
as  appropriate. 

Changes  to  the  organization’s  standard  software  process  (as  described  in  the 
Organization  Process  Definition  key  process  area)  and  the  projects’  defined 
software  processes  (as  described  in  the  Integrated  Software  Management  key 
process  area)  resulting  from  these  technology  changes  are  handled  as  described  in 
the  Process  Change  Management  key  process  area.  (L5-17) 


Continued  on  next  page 
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TCM  Process  -  Overview,  Continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L5-Process-37 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L5-Process-44 

Inputs 

Description  of  the  work  products  used  by 
the  process. 

L5-Process-46 

Activities 

Description  of  the  activities  of  the 
process. 

L5-Process-48 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L5-Process-52 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L5-Process-57 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L5-Process-69 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled.. 

L5-Process-71 

Measurements 

Description  of  process  measurements. 

L5-Process-72 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L5-Process-73 

Training 

List  of  training. 

L5-Process-74 

Tools 

List  of  tools. 

L5-Process-75 
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TCM  Process  -  Roles 


Roles 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
technology  change  management  process. 


Roles 

Activities  Participated  in... 

Reference 

Affected 

managers 

The  plan  for  technology  change 
management  is  reviewed  by  the  affected 
managers.  (L5-24,  Al,  6) 

i 

Group 

responsible  for 
the 

organization's 

technology 

change 

management 

activities 

□  The  group  responsible  for  the 
organization's  technology  change 
management  activities  coordinates  and 
helps  to  (L5-20,  Abl,  2): 

□  explore  potential  areas  for  applying 
new  technology; 

□  select  and  plan  for  new 
technologies; 

□  acquire,  install,  and  customize  new 
technologies; 

□  communicate  and  coordinate  with 
related  research  and  development 
activities  within  the  organization; 
and 

□  communicate  with  the  technology 
suppliers  on  problems  and 
enhancements. 

□  Experienced  staff  members  with 

expertise  in  specialized  areas  are 
available  to  this  group  responsible  for 
the  organization's  technology  change 
management  activities  to  help  in 
evaluating,  planning,  and  supporting 
initiatives  for  technology  change 
management.  Ab2.  ll 

□  Members  of  the  group  responsible  for 
the  organization's  technology  change 
management  activities  receive  required 
training  to  perform  these  activities. 
(L5-23,  Ab5) 

□  The  group  responsible  for  the 
organization's  technology  change 
management  activities  works  with  the 
software  projects  in  identifying  areas  of 
technology  change.  (L5-24,  A2) 

Role  continued  on  next  page 
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TCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
technology  change  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Role  continued  from  previous  page 

_ I 

Group 

responsible  for 
the 

organization's 

technology 

change 

management 

activities, 

continued 

_ I 

□  The  group  rc  sponsible  for  the 
organization's  technology  change 
management  activities:  (L5-24,  A2) 

□  Solicits  suggestions  for  technology 
changes. 

□  Identifies  available  new 
technologies  that  may  be 
appropriate  to  the  organization's 
and  projects'  needs. 

□  A  periodic  search  is  made  to 
identify  commercially  available 
technologies  that  meet 
identified  and  anticipated 
needs. 

□  Systematic  efforts  are  made  to 
maintain  awareness  of  leading 
relevant  technical  work  and 
trends  of  new  technologies. 

□  Systematic  efforts  are  made  to 
review  the  technologies  used 
externally  and  to  compare  these 
technologies  to  those  used 
within  the  organization. 

□  Areas  where  new  technologies 
have  been  used  successfully  are 
identified,  and  data  and 
documentation  of  experience 
with  using  them  are  collected 
and  reviewed. 

□  Evaluates  new  technologies  to 
determine  their  applicability  to  the 
organization’s  and  projects'  current 
and  future  needs. 

j 

Role  continued  on  next  page 
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TCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
technology  change  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Role  continued  from  previous  page 

Group 

responsible  for 
the 

organization's 

technology 

change 

management 

activities, 

continued 

□  The  group  responsible  for  the 
organization's  technology  change 
management  systematically  analyzes 
the  organization's  standard  software 
process  to  identify  areas  that  need  or 
could  benefit  from  new  technology. 
(L5-25,  A4) 

The  group  responsible  for  the 
organization's  technology  change 
management  activities:  (LS-25,  A4) 

□  Analyzes  the  organization's 
standard  software  process  to 
determine  areas  where  new 
technologies  would  be  most 
helpful. 

□  Identifies  helpful  technology 
changes  and  determines  the 
economics  of  those  changes. 

□  Defines  the  relationship  of  the 
identified  technology  to  the 
organization's  standard  software 
process. 

□  Defines  the  expected  outcomes  of 
the  technology  change  qualitatively 
and  quantitatively,  as  appropriate. 

□  Determines  the  need  for  piloting 
each  potential  technology  change., 

□  Determines  the  priority  of  the 
candidate  new  technologies. 

□  Documents  results  of  the  analysis 
activities. 

Role  continued  on  next  page 
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TCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
technology  change  management  process,  continued  from  the  previous  page. 


2 

Role 

Activities  Participated  in... 

Reference 

Role  continued  from  previous  page 

Group 

responsible  for 
the 

organization's 

technology 

change 

management 

activities, 

continued 

□  The  requirements  and  plans  are 
reviewed  by  the  managers  of  the 
affected  groups  and  the  group 
responsible  for  technology  change 
management  activities.  (L5-26,  A5, 
4.4) 

□  The  group  responsible  for  technology 
change  management  activities 
provides  consultation  and  assistance  to 
the  project  implementing  the  pilot 
effort  (for  improving  technology). 
(L5-27,  A6,  4) 

Managers  of 
the  affected 
groups 

□  The  requirements  and  plans  are 
reviewed  by  the  managers  of  the 
affected  groups  and  the  group 
responsible  for  technology  change 
management  activities.  (L5-26,  A5, 

4.4) 

□  The  plan  for  conducting  the  pilot  effort 
is  reviewed  and  approved  by  the 
managers  of  the  affected  groups.  (L5- 
27,  A6,  3) 

Organization’s 

managers 

□  Senior  management  coordinates  with 
the  organization's  managers  in 
defining  their  goals  and  approaches  for 
accomplishing  the  organization's 
strategy.  (L5-19,  C2,  3) 

□  Senior  management  coordinates  with 
the  organization's  managers  to  secure 
the  managers'  and  staffs  support  and 
participation.  (L5-20,  C3,  4.2) 

Continued  on  next  page 
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TCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
technology  change  management  process,  continued  from  the  previous  page. 


V 

Role 

Activities  Participated  in... 

Reference 

Senior 

management 

□  Senior  management  sponsors  the 

organization's  activities  for  technology 

change  management.  (L5-19,  C2) 

Senior  management; 

□  Helps  to  define  a  strategy  that 
addresses  the  organization's  goals 
for  product  quality,  productivity, 
and  cycle  time  for  product 
development. 

□  Helps  to  define  a  strategy  that 
addresses  the  customer’s  and  end 
users'  needs  and  desires,  as 
appropriate. 

□  Coordinates  with  the  organization's 
managers  in  defining  their  goals 
and  approaches  for  accomplishing 
the  organization’s  strategy. 

□  Makes  a  commitment  to  the  effort 
for  technology  change 
management  that  is  visible 
throughout  the  organization. 

□  Establishes  long-term  plans  and 
commitments  for  funding,  staffing, 
and  other  resources. 

Role  continued  on  next  page 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L5«Process-41 


TCM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
technology  change  management  process,  continued  from  the  previous  page. 


Tl 

Role 

Activities  Participated  in... 

Reference 

Role  continued  from  previous  page 

Senior 

management, 

continued 

□  Senior  management  oversees  the 
organization's  technology  change 
management  activities.  (L5-I9,  C3) 

Senior  management: 

□  Helps  to  establish  policies  for 
technology  change  management 
and  reviews  and  approves  these 
policies. 

□  Allocates  resources  for  technology 
change  management  activities. 

□  Helps  relate  organizational 
strategies  and  objectives  to 
strategies  for  technology  change 
management. 

□  Participates  in  establishing  the  plans 
for  technology  change 
management. 

□  Senior  management 
coordinates  requirements  and 
issues  for  technology  change 
management  at  all  appropriate 
levels  of  the  organization. 

□  Senior  management 
coordinates  with  the 
organization's  managers  to 
secure  the  managers'  and  staffs 
support  and  participation. 

□  The  organization’s  activities  for 
technology  change  management  are 
reviewed  with  senior  management  on  a 
periodic  basis.  (L5-29,  VI) 

Continued  on  next  page 
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TCM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
technology  change  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Software 

manager 

Software  managers  and  technical  staff  are 
kept  informed  of  new  technologies.  (L5- 
25,  A3) 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  technology  change 
management  and  reports  the  results.  (L5- 
29,  V2) 

Staff 

□  Senior  management  coordinates  with 
the  organization's  managers  to  secure 
the  managers'  and  staffs  support  and 
participation.  (L5-20,  C3,  4.2) 

□  Experienced  staff  members  with 
expertise  in  specialized  areas  are 
available  to  this  group  to  help  in 
evaluating,  planning,  and  supporting 
initiatives  for  technology  change 
management.  (L5-21,  Ab2,  1) 

□  Software  managers  and  technical  staff 
are  kept  informed  of  new  technologies. 
(L5-25,  A3) 

Technology 

suppliers 

The  group  responsible  for  the 
organization's  technology  change 
management  activities  coordinates  and 
helps  to  communicate  with  the  technology 
suppliers  on  problems  and  enhancements. 
(L5-2I,  Abl,  2.5) 
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TCM  Process  -  Entry  Criteria 


Input'based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  technology  change  management  process. 


Input 

State 

References 

Data  on  the  software 
processes 

are  available  to  support  analyses 
performed  to  evaluate  and  select 
technology  changes.  (L5-22,  Ab4) 

Data  on  the  software 
work  products 

are  available  to  support  analyses 
performed  to  evaluate  and  select 
technology  changes.  (L5-22,  Ab4) 

Needs  of  the 
organization  (current 
and  future) 

□  are  identified.  (L5-24,  A2,  2.1) 

□  are  anticipated.  (L5-24,  A2,  2.1) 

Needs  of  the  projects 
(current  and  future) 

□  are  identified.  (L5-24,  A2,  2.1) 

□  are  anticipated.  (L5-24,  A2,  2.1) 

Selection  criteria  to 
identify  the  highest 
potential  benefits  (for 
selecting 
technologies) 

□  are  predefined.  (L5-26,  A5,  3) 

□  are  approved.  (L5-26,  A5,  3) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  technology  change  management  process. 


T 

Condition 

References 

The  organization  follows  a  written  policy  for  improving  its 
technology  capability.  (L5-18,  Cl) 

[Refer  to  Level  5  Policies  for  additional  information 
regarding  TCM  policy.] 

Senior  management  sponsors  the  organization's  activities 
for  technology  change  management.  (L5-19,  C2) 

A  group  responsible  for  the  organization's  technology 
change  management  activities  exists.  (L5-20,  Abl) 

□  The  group  is  either  part  of  the  group  responsible  for  the 
organization's  software  process  activities  (e.g.,  software 
engineering  process  group)  or  its  activities  are  closely 
coordinated  with  that  group.  (L5-20,  Abl,  1) 

Adequate  resources  and  funding  are  provided  to  establish 
and  staff  a  group  responsible  for  the  organization's 
technology  change  management  activities.  (L5-21,  Ab2) 

Continued  on  next  page 
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TCM  Process  -  Entry  Criteria,  ConUnued 


General  entry 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  technology  change  management  process,  continued  from  the 
previous  page. 


~T 

Condition 

References 

Experienced  staff  members  with  expertise  in  specialized 
areas  are  available  to  this  group  (responsible  for  the 
organization’s  technology  change  management  activities) 
to  help  in  evaluating,  planning,  and  supporting  initiatives  for 
technology  change  management.  (L5-21,  Ab2,  1) 

Tools  to  support  technology  change  management  are  made 
available.  (L5-21.  Ab2,  2) 

Support  exists  for  collecting  and  analyzing  data  needed  to 
evaluate  technology  changes.  (L5-21,  Ab3) 

This  support  includes  the  ability  to: 

□  Record  selected  process  and  product  data  automatically. 

□  Support  data  analysis. 

□  Display  selected  data. 

Members  of  the  group  responsible  for  the  organization's 
technology  change  management  activities  receive  required 
training  to  perform  these  activities.  (L5-23,  Ab5) 
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TCM  Process  -  inputs,  Continued 


Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  technology  change 
management  process,  continued  from  the  previous  page. 


^l 

Input 

Org.  Input 

References 

Potential  technology  changes.  (L5-26,  A4, 
5) 

Requirements  for  technology  change 
management.  (L5-20,  C3,  4.1) 

Revisions  to  the  plans  for  technology 
change  management.  (L5-29,  VI,  4) 

Selection  criteria  (for  selecting 
technologies)  to  identify  the  highest 
potential  benefits.  (L5-26,  A5,  3) 

Suggestions  for  technology  changes.  (L5- 
24,  A2,  1) 

Technologies  used  externally  (to  the 
organization).  (L5-25,  A2,  2.3) 

Technologies  used  within  the  organization. 
(L5-25,  A2,  2.3) 

Technology  changes.  (L5-21,  Ab3) 

Untried  technologies.  (L5-27,  A6,  1 ) 

CMU/SEI-94-HB-1 


L5-Process-47 


TCM  Process  -  Inputs,  Continued 


Inputs, 

continued 


The  table  below  lists  the  recommended  inputs  to  the  technology  change 
management  process,  continued  from  the  previous  page. 


V 

Input 

Org.  Input 

References 

Potential  technology  changes.  (L5-26,  A4, 
5) 

Requirements  for  technology  change 
management.  (L5-20,  C3,  4.1) 

Revisions  to  the  plans  for  technology 
change  management.  (L5-29,  VI,  4) 

Selection  criteria  (for  selecting 
technologies)  to  identify  the  highest 
potential  benefits.  (L5-26,  A5,  3) 

Suggestions  for  technology  changes.  (L5- 
24,  A2,  1) 

Technologies  used  externally  (to  the 
organization).  (L5-25,  A2.  2.3) 

Technologies  used  within  the  organization. 
(L5-25,  A2,  2.3) 

Technology  changes.  (L5-21,  Ab3) 

Untried  technologies.  (L5-27,  A6,  1) 
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TCM  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  technology  change 
management  process. 


Activities 

References 

The  organization  develops  and  maintains  a  plan  for 
technology  change  management.  (L5-23,  AI) 

The  group  responsible  for  the  organization’s  technology 
change  management  activities  works  with  the  software 
projects  in  identifying  areas  of  technology  change.  (L5-24, 
A2) 

This  group: 

□  Solicits  suggestions  for  technology  changes. 

□  Identifies  available  new  technologies  that  may  be 
appropriate  to  the  organization’s  and  projects'  needs. 

□  A  periodic  search  is  made  to  identify  commercially 
available  technologies  that  meet  identified  and 
anticipated  needs. 

□  Systematic  efforts  are  made  to  maintain  awareness  of 
leading  relevant  technical  work  and  trends  of  new 
technologies. 

□  Systematic  efforts  are  made  to  review  the 
technologies  used  externally  and  to  compare  these 
technologies  to  those  used  within  the  organization. 

□  Areas  where  new  technologies  have  been  used 
successfully  are  identified,  and  data  and 
documentation  of  experience  with  using  them  are 
collected  and  reviewed. 

□  Evaluates  new  technologies  to  determine  their 
applicability  to  the  organization's  and  projects’  current 
and  future  needs. 

Software  managers  and  technical  staff  are  kept  informed  of 

new  technologies.  (L5-25,  A3) 

□  Information  on  new  technologies  is  disseminated  as 
appropriate. 

□  Information  on  advanced  technologies  already  in  use  in 
parts  of  the  organization  is  disseminated  as  appropriate. 

□  Information  on  the  status  of  technologies  being 
transferred  into  the  organization  is  disseminated  as 
appropriate. 

Continued  on  next  page 
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TCM  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  technology  change 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  group  responsible  for  the  organization's  technology 
change  management  systematically  analyzes  the 
organization's  standard  software  process  to  identify  areas 
that  need  or  could  benefit  from  new  technology.  (L5-25, 

A4) 

This  group: 

□  Analyzes  the  organization's  standard  software  process  to 
determine  areas  where  new  technologies  would  be  most 
helpful. 

□  Identifies  helpful  technology  changes  and  determines 
the  economics  of  those  changes. 

□  Defines  the  relationship  of  the  identified  technology  to 
the  organization's  standard  software  process. 

□  Defines  the  expected  outcomes  of  the  technology 
change  qualitatively  and  quantitatively,  as  appropriate. 

□  Determines  the  need  for  piloting  each  potential 
technology  change. 

□  Determines  the  priority  of  the  candidate  new 
technologies. 

□  Documents  results  of  the  analysis  activities. 

Technologies  are  selected  and  acquired  for  the  organization 
and  software  projects  according  to  a  documented  procedure. 
(L5-26,  A5) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

Continued  on  next  page 
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TCM  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  technology  change 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

Pilot  efforts  for  improving  technology  are  conducted,  where 
appropriate,  before  a  new  technology  is  introduced  into 
normal  practice.  (L5-27,  A6) 

□  These  pilot  efforts  are  conducted  to  determine  the 
feasibility  and  economics  of  untried  or  advanced 
technologies. 

□  The  plans  for  the  pil-jt  effcrt  are  documented. 

□  The  plan  for  conducting  the  pMot  effort  is  reviewed  and 
approved  by  the  man  -  gers  uf  Ute  at..  ,cA  groups. 

□  The  group  responsible  -•  .r.jogy  change 

management  activities  te;  c-.-.isuitation  and 

assistance  to  the  project  implementing  the  pilot  effort. 

□  The  pilot  effort  is  pc'^'ormed  in  an  environment  that  is 
rele^'ant  to  the  deve'  >  -at  or  maintenance 
eavnun.Tient. 

□  The  f  ‘.suits  of  the  p'lot  effort  are  collected,  analyzed,  and 
docamented. 

T  Lessons  lean"  '.c  cr.  i  problems  e  jcountered  during 
th  '.Tort  are  t.' 

j  Tae  benefits  auu  imp..^.  t  broader  use  in  the 
organization  are  esti.nat. The  uncertainty  in  these 
estimates  is  assessed. 

□  A  decision  is  made  whether  to  terminate  the  effort, 
proceed  with  broad-scale  implementation  of  the 
technology,  or  replan  and  continue  the  pilot  effort. 

I 

Appropriate  new  technologies  are  incorporated  into  the 
organization's  stand.ard  software  process  according  to  a 
documented  procedure.  (L5-28,  A7) 

Appropriate  new  te.  '•.>,ologies  are  incorporated  into  the 
projects'  defined  software  processes  according  to  a 
documented  procedure.  (L5-28,  A8) 

Measurements  are  made  and  used  to  determine  the  status  of 
the  organization's  activities  for  technology  change 
management.  (L5-28,  Ml) 

The  organization's  activities  for  technology  change 
management  are  reviewed  with  senior  management  on  a 
periodic  basis.  (L5-29,  VI) 

[Refer  to  TCM  Process  Reviews  and  Audits  for  additional 
information.] 

Continued  on  next  page 


L5-Process-50 


CMU/SEI-94-HB-1 


TCM  Process  ■  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  technology  change 
management  process,  continued  from  the  previous  page. 


Activities 

References 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  technology  change 
management  and  reports  the  results.  (L5-29,  V2) 

[Refer  to  TCM  Process  Reviews  and  Audits  for  additional 
information.] 
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TCM  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  technology 
change  management  process. 


Output 

Org.  Output 

References 

Approach  for  introducing  new 
technologies  to  address  specific  needs  of 
the  organization  and  projects  (L5-24,  Al, 
4) 

Approaches  for  accomplishing  the 
organization's  strategy.  (L5-19,  C2,  3) 

Approaches  for  assessing  unproven 
candidate  technologies.  (L5-24,  Al,  4.6) 

Approaches  for  identifying  opportunities 
for  technology  changes.  (L5-24,  Al,  4.2) 

Areas  of  technology  change.  (L5-24,  A2) 

Areas  that  need  or  could  benefit  from  new 
technology.  (L5-25,  A4) 

Areas  where  new  technologies  have  been 
used  successfully.  (L5-25,  A2,  2.4) 

Areas  where  new  technologies  would  be 
most  helpful.  (L5-25,  A4,  1) 

Available  new  technologies  that  may  be 
appropriate  to  the  organization's  and 
projects'  needs.  (L5-24,  A2,  2) 

Benefits  of  (a  new  technology’s)  broader 
use  in  the  organization  (based  on  the 
results  of  the  pilot  efforts  for  improving 
technology).  (L5-28,  A6,  6.2) 

Candidate  technologies.  (L5-24,  Al,  4.3) 

Commercially  available  technologies  that 
meet  identified  and  anticipated  needs. 
(L5-24,  A2,  2.1) 

Commitment  to  the  effort  for  technology 
change  management.  (L5-19,  C2,  4) 

Commitments  for  funding,  staffing,  and 
other  resources  (for  technology  change 
management  activities).  (L5-19,  C2,  5) 

Data  needed  to  evaluate  technology 
changes.  (L5-21,  Ab3) 

Data  of  experience  (with  using  new 
technologies  in  areas  where  they  have  been 
used  successfully).  (L5-25,  A2,  2.4) 

Continued  on  next  page 
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TCM  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  technology 
change  management  process,  continued  from  the  previous  page. 


V 

Output 

Org.  Output 

References 

Decision  whether  to  terminate  the  effort 
(pilot  effort  for  improving  technology), 
proceed  with  broad-scale  implementation 
of  the  technology,  or  replan  and  continue 
the  pilot  effort.  (L5-28,  A6,  6.3) 

Documentation  of  experience  (with  using 
new  technologies  in  areas  where  they  have 
been  used  successfully).  (L5-25,  A2,  2.4) 

Enhancements  (to  technology).  (L5-21, 
Abl,  2.5) 

Evaluation  criteria  for  the  pilot  effort. 
(L5-27,  A6,  2.1) 

Expected  life  span  for  replacement/ 
upgrade.  (L5-26,  A5,  4.1) 

Expected  outcomes  of  the  technology 
change.  (L5-26,  A4,  4) 

Goals  for  accomplishing  the  organization’s 
strategy.  (L5-19,  C2,  3) 

Impacts  of  (a  new  technology’s)  broader 
use  in  the  organization  (based  on  the 
results  of  the  pilot  efforts  for  improving 
technology).,  (L5-28,  A6,  6.2) 

Information  on  advanced  technologies 
already  in  use  in  parts  of  the  organization. 
(L5-25,  A3,  2) 

Information  on  new  technologies.  (L5-25, 
A3,  1) 

Information  on  the  status  of  technologies 
being  transferred  into  the  organization. 
(L5-25,  A3,  3) 

Lessons  learned  encountered  during  the 
(pilot)  effort.  (L5-27,  A6,  6.1) 

Life  span  for  the  planned  technologies 
(from  introduction  to  replacement).  (L5- 
24,  A  1,4.4) 

Long-term  plans  for  funding,  staffing,  and 
other  resources.  (L5-19,  C2,  5) 

Continued  on  next  page 
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TCM  Process  -  Outputs,  Continued 


Outputs, 

continu^ 


The  table  below  lists  the  recommended  outputs  produced  by  the  technology 
change  management  process,  continued  from  the  previous  page. 


T 

Output 

Org.  Output 

References 

Long-term  technical  strategy  (for 
automating  and  improving  the 
organization's  standard  software  process 
and  enhancing  the  organization's  market 
position).  (L5-23,  Al,  2) 

Make/buy  tradeoff  studies  (for  introducing 
new  technology).,  (L5-24,  Al,  4.5) 

Measurements  to  determine  the  status  of 
the  organization's  activities  for  technology 
change  management.  (L5-28,  Ml) 

Need  for  piloting  each  norential 
technology  change  ’  o,  A4.  J, 

Needed  strategy  cb-'f.ges  ■'L5-29,  vl,  2) 

New  tech.'ologie;  ..f-21,  Abl,  2.2) 

Objectives  for  technology  change 
management.  (L5-18,  Cl,  1) 

Objectives  for  the  pilot  effort.  (L5-27,  A6, 
2.1) 

Organization's  standard  software  process. 
(L5-28,  A7) 

Organizational  objectives.  (L5-20,  C3,  3) 

Organizational  strategies.  (L5-20,  C3,  3) 

Plan  for  conducting  the  pilot  effort.  (L5- 
27,  A6,  2) 

[Refer  to  Level  5  Standards  for  additional 
information  regarding  this  plan.] 

Plan  for  technology  change  management. 
(L5-19,  Cl,2) 

[Refer  to  Level  5  Standards  for  additional 
information  regarding  this  plan.] 

Planned  technologies.  (L5-24,  Al,  4.3) 

Plans  for  the  selected  technology  changes. 
(L5-26,  A5,  4) 

Potential  areas  for  applying  new 
technology.  (L5-20,  Abl,  2.1) 

Priority  of  the  candidate  new  technologies. 
(L5-26,  A4,  6) 

Continued  on  next  page 
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TCM  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  technology 
change  management  process,  continued  from  the  previous  page. 


T 

Output 

Org.  Output 

References 

Problems  encountered  during  the  (pilot) 
effort.  (L5-27,  A6.  6.1) 

Problems  (with  technology).  (L5-21,  Abl, 
2.5) 

Process  areas  that  are  potential  areas  for 
technology  changes.  (L5-24,  Al,  4.1) 

Process  data  (selected).  (L5-22,  Ab3,  1) 

Product  data  (selected).  (L5-22,  Ab3,  1) 

Projects'  defined  software  processes.  (L5- 
28,  A8) 

Relationship  of  the  identified  technology 
to  the  organization's  standard  software 
process.  (L5-25,  A4,  3) 

Requests  for  the  acquisition  of  new 
technologies.  (L5-26,  AS,  1) 

Requirements  for  the  selected  technology 
changes.  (L5-26,  A5,  4) 

Results  (of  the  software  quality  assurance 
group  reviews  and/or  audits  of  the  activities 
and  work  products  for  technology  change 
management).  (L5-29,  V2) 

Results  of  the  analysis  activities  (for 
performing  systematic  analysis  of  the 
organization's  standard  software  process  to 
identify  areas  that  need  or  could  benefit 
from  new  technology).  (L5-26,  A4,  7) 

Results  of  the  pilot  effort  (for  improving 
technology).  (L5-27,  A6,  6) 

Strategies  for  technology  change 
management.  (L5-20,  C3,  3) 

Strategy  that  addresses  the  customer's  and 
end  users'  needs  and  desires.  (L5-19,  C2, 

2) 

Strategy  that  addresses  the  organization's 
goals  for  product  quality,  productivity,  and 
cycle  time  for  product  development.  (L5- 
19,  C2,  1) 
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TCM  Process  -  Outputs,  Continued 


Outputs, 

continu^ 


The  table  below  lists  the  recommended  outputs  produced  by  the  technology 
change  management  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Technologies  with  projected  expenses 
above  a  predefined  level.  (I^j-26,  A5,  1.1) 

Technologies.  (L5-26,  A5) 

Technology  changes.  (L5-22,  Ab4) 

Tradeoff  studies  (to  determine  whether  the 
technology  should  be  developed  internally 
or  procured  externally).  (L5-26,  A5,  4.2) 

Uncertainty  in  the  estimates  of  benefits  of 
(a  new  technology’s)  broader  use  in  the 
organization  (based  on  the  results  of  the 
pilot  efforts  for  improving  technology). 
(L5-28.  A6,  6.2) 

Uncertainty  in  the  estimates  of  impacts  of 
(a  new  technology’s)  broader  use  in  the 
organization  (based  on  the  results  of  the 
pilot  efforts  for  improving  technology). 
(L5-28,  A6,  6.2) 
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TCM  Process  -  Exit  Criteria 


Output-based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process. 


T 

Output 

State 

References 

Approaches  for 
accomplishing  the 
organization's 
strategy 

are  defined  by  coordination  between 
the  organization's  managers  and 
senior  management.  (LS-19,  C2,  3) 

Areas  of  technology 
change 

are  identified  by  the  group 
responsible  for  the  organization's 
technology  change  management 
activities  working  with  the  software 
projects.  (L5-24,  A2) 

Areas  that  need  or 
could  benefit  from 
new  technology 

are  identified  by  the  group 
responsible  for  the  organization's 
technology  change  management  by 
systematically  analyzing  the 
organization's  standard  software 
process.  (L5-25,  A4) 

Areas  where  new 
technologies  have 
been  used 
successfully 

are  identified  by  the  group 
responsible  for  the  organization's 
technology  change  management 
activities.  (L5-25,  A2,  2.4) 

Areas  where  new 
technologies  would 
be  most  helpful 

are  determined  by  the  group 
responsible  for  the  organization's 
technology  change  management  by 
analyzing  the  organization's  standard 
software  process.  {L5-25,  A4, 1) 

Available  new 
technologies  that 
may  be  appropriate 
to  the  organization's 
and  projects'  needs 

are  identified  by  the  group 
responsible  for  the  organization's 
technology  change  management 
activities.  (L5-24,  A2,  2) 

Benefits  of  (a  new 
technology’s) 
broader  use  in  the 
organization  (based 
on  the  results  of  the 
pilot  efforts  for 
improving 
technology) 

are  estimated.  (L5*28,  A6,  6.2) 

Commercially 
available 
technologies  that 
meet  identified  and 
anticipated  needs 

are  identified  by  a  periodic  search  by 
the  group  responsible  for  the 
organization's  technology  change 
management  activities.  (L5-24,  A2, 
2.1) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  ‘hat  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Commitment  to  the 
effort  for  technology 
change  management 

□  is  made  by  senior  management. 
(L5-19,  C2,  4) 

□  is  visible  throughout  the 
organization.  (L5-19,  C2,  4) 

Commitments  for 
funding,  staffing,  and 
other  resources 

are  established  by  senior 
management.  (LS-19,  C2,  S) 

Data  of  experience 
(in  areas  where  new 
technologies  have 
been  used 
successfully) 

□  are  collected  by  the  group 
responsible  for  the 
organization's  technology 
change  management  activities. 
(L5-25.  A2,  2.4) 

□  are  reviewed  by  the  group 
responsible  for  the 
organization's  technology 
change  management  activities. 
(L5-25,  A2,  2.4) 

Decision  whether  to 
terminate  the  effort 
(pilot  effort  for 
improving 

technology),  proceed 
with  broad-scale 
implementation  of 
the  technology,  or 
replan  and  continue 
the  pilot  effort 

is  made.  (L5-28,  A6,  6.3) 

Documentation  of 
experience  (in  areas 
where  new 
technologies  have 
been  used 
successfully) 

□  is  collected  by  the  group 
responsible  for  the 
organization's  technology 
change  management  activities. 
(L5-25,  A2,  2.4) 

□  is  reviewed  by  the  group 
responsible  for  the 
organization's  technology 
change  management  activities. 
(L5-25,  A2,  2.4) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Enhancements  (to 
technology) 

are  communicated  to  the  technology 
suppliers  (with  coordination  and 
help  from  the  group  responsible  for 
the  organization's  technology 
change  management  activities). 
(L5-21,  Abl,  2.5) 

Expected  life  span 
for  replacement/ 
upgrade 

is  estimated,  where  practical.  (L5-26, 
A5,  4.1) 

Expected  outcomes 
of  the  technology 
change 

□  are  defined  qualitatively  by  the 
group  responsible  for  the 
organization's  technology 
change  management,  as 
appropriate.  (L5-26,  A4,  4) 

□  are  defined  quantitatively  by  the 
group  responsible  for  the 
organization's  technology 
change  management,  as 
appropriate.  (L5-26,  A4,  4) 

Goals  for 
accomplishing  the 
organization's 
strategy 

are  defined  by  senior  management 
coordinating  with  the  organization's 
managers.  (L5-19,  C2,  3) 

Impacts  of  (a  new 
technology’s) 
broader  use  in  the 
organization  (based 
on  the  results  of  the 
pilot  efforts  for 
improving 
technology) 

are  estimated.  (L5-28,  A6,  6.2) 

Information  on 
advanced 

technologies  already 
in  use  in  parts  of  the 
organization 

is  disseminated  as  appropriate.  (L5- 
25,  A3,  2) 

Information  on  new 
technologies 

is  disseminated  as  appropriate.  (L5- 
25,  A3,  1) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Information  on  the 
status  of  technologies 
being  transferred  into 
the  organization 

is  disseminated  as  appropriate.  (L5- 
25,  A3,  3) 

Lessons  learned  that 
are  encountered 
during  the  (pilot) 
effort 

are  documented.  (L5-27,  A6,  6.1) 

Life  span  for  the 
planned  technologies 
(from  introduction  to 
replacement) 

is  estimated,  where  appropriate.  (L5- 
24,  Al.  4.4) 

Long-term  plans  for 
funding,  staffing,  and 
other  resources  (for 
technology  change 
management 
activities) 

are  established  by  senior 
management.  (L5-19,  C2, 5) 

Long-term  technical 
strategy  (for 
automating  and 
improving  the 
organization's 
standard  software 
process  and 
enhancing  the 
organization's  market 
position) 

is  defined  in  the  plan  for  technology 
change  management.  (L5-23,  Al,  2) 

Make/buy  tradeoff 
studies  (for 
introducing  new 
technology) 

are  documented.  (L5-24,  Al,  4.5) 

Measurements  (to 
determine  the  status 
of  the  organization's 
activities  for 
technology  change 
management) 

□  are  made.  (L5-28,  Ml) 

□  are  used.  (L5-28,  Ml) 

Need  for  piloting 
each  potential 
technology  change 

is  determined  by  the  group 
responsible  for  the  organization's 
technology  change  management. 
(L5-26,  A4,  5) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


Output 

State 

References 

Needed  strategy 
changes 

are  identified  in  periodic  reviews  with 
senior  management.  (L5-29,  VI,  2) 

New  technologies 

□  are  selected  (with  coordination 
and  help  from  the  group 
responsible  for  the 
organization's  technology 
change  management  activities). 
(L5-21,  Abl,  2.2) 

□  are  planned  (with  coordination 
and  help  from  the  group 
responsible  for  the 
organization's  technology 
change  management  activities). 
(L5-21,  Abl,  2.2) 

□  are  acquired  (with  coordination 
and  help  from  the  group 
responsible  for  the 
organization's  technology 
change  management  activities). 
(L5-21,  Abl,  2.3) 

□  are  installed  (with  coordination 
and  help  from  the  group 
responsible  for  the 
organization's  technology 
change  management  activities). 
(L5-21,  Abl,  2.3) 

□  are  customized  (with 
coordination  and  help  from  the 
group  responsible  for  the 
organization's  technology 
change  management  activities). 
(L5-21,  Abl,  2.3) 

Objective.s  for 
technology  change 
management 

□  are  established.  (L5-18,  Cl,  1) 

□  are  documented.  (L5-18,  Cl,  1) 

Organization's 
standard  software 
process 

has  incorporated  appropriate  new 
technologies  according  to  a 
documented  procedure.  (L5-28,  A7) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Organizational 

objectives 

are  related  to  strategies  for 
technology  change  management 
(with  senior  management’s  help). 
(L5-20,  C3,  3) 

Organizational 

strategies 

are  related  to  strategies  for 
technology  change  management 
(with  senior  management’s  help). 
(L5-20.  C3,  3) 

Plan  for  conducting 
the  pilot  effort  (for 
improving 
technology) 

□  is  documented.  (L5-27,  A6,  2) 

□  is  reviewed  by  the  managers  of 
the  affected  ^oups.  (LS-27,  A6, 
3) 

□  is  approved  by  the  managers  of 
the  affected  groups.  (LS-27,  A6, 
3) 

Plan  for  technology 
change  management 

□  is  documented.  (L5-19,  Cl,  2) 

□  addresses  the  objectives  for 
technology  change  management. 
(L5-19,  Cl,  2) 

□  is  established  (with  senior 
management  participation). 
(L5-20,  C3, 4) 

□  is  developed  by  the  organization. 
(L5-23,  Al) 

□  is  maintained  by  the 
organization.  (L5-23,  Al) 

□  undergoes  peer  review.  (L5-24, 
Al,5) 

□  is  reviewed  by  the  affected 
managers.  (L5-24,  Al,6) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Plans  for  the  selected 
technology  changes 

□  are  defined.  (L5-26,  A5,  4) 

□  are  documented.  (L5-26,  A5,  4) 

□  are  estimated.  (L5-26,  A5,  4.1) 

□  provide  for  installing  the  new 
technology  on  a  pilot  basis  to 
determine  its  effectiveness  and 
economic  benefits.  (L5-26,  A5, 
4.3) 

□  are  reviewed  by  the  managers  of 
the  affected  groups  and  the 
group  responsible  for 
technology  change  management 
activities.  (L5-26,  A5, 4.4) 

Potential  areas  for 
applying  new 
technology 

are  explored  (with  coordination  and 
help  from  the  group  responsible  for 
the  organization's  technology 
change  management  activities). 
(L5-20,  Abl,  2.1) 

Priority  of  the 
candidate  new 
technologies 

is  determined  by  the  group 
responsible  for  the  organization's 
technology  change  management. 
(L5-26,  A4,  6) 

Problems  (with 
technology) 

are  communicated  to  the  technology 
suppliers  (with  coordination  and 
help  from  the  group  responsible  for 
the  organization's  technology 
change  management  activities). 
(L5-21,  Abl,  2.5) 

Problems 

encountered  during 
the  (pilot)  effort 

are  documented.  (L5-27,  A6,  6.1) 

Projects’  defined 
software  processes 

have  incorporated  appropriate  new 
technologies  according  to  a 
documented  procedure.  (LS-28,  A8) 

Relationship  of  the 
identified  technology 
to  the  organization's 
standard  software 
process 

is  defined  by  the  group  responsible 
for  the  organization's  technology 
change  management.  (LS-2S,  A4, 

3) 

Continued  on  next  page 


CMU/SEI-94-HB-1 


L5>Process«63 


TCM  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Requests  for  the 
acquisition  of  new 
technologies 

are  documented.  (LS-26,  AS,  1) 

Requirements  for  the 
selected  technology 
changes 

□  are  defined.  (L5-26,  AS,  4) 

□  are  documented.  (LS-26,  AS,  4) 

□  are  reviewed  by  the  managers  of 
the  affected  groups  and  the 
group  responsible  for 
technology  change  management 
activities.  (LS-26,  AS,  4.4) 

Results  (of  the 
software  quality 
assurance  group 
reviews  anchor  audits 
of  the  activities  and 
work  products  for 
technology  change 
management) 

are  reported.  (LS-29,  V2) 

Results  of  the 
analysis  activities 
(from  the  systematic 
analysis  of  the 
organization's 
standard  software 
process  to  identify 
areas  that  need  or 
could  benefit  from 
new  technology) 

are  documented  by  the  group 
responsible  for  the  organization's 
technology  change  management. 
(LS-26.  A4,  7) 

Results  of  the  pilot 
effort  (for  improving 
technology) 

□  are  collected.  (LS-27,  A6,  6) 

□  are  analyzed.  (LS-27,  A6,  6) 

□  are  documented.  (LS-27,  A6,  6) 

Strategies  for 
technology  change 
management 

are  related  to  organizational 
strategies  and  objectives  (with  senior 
management’s  help).  (LS-20,  C3,  3) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Strategy  that 
addresses  the 
customer's  and  end 
users'  needs  and 
desires 

is  defined  (with  senior 
management’s  heb),  as  appropriate. 
(L5-19,  C2,  2) 

Strategy  that 
addresses  the 
organization's  goals 
for  product  quality, 
productivity,  and 
cycle  time  for 
product  development 

is  defined  (with  senior 
management’s  help).  (L5-19,  C2, 1) 

Technologies 

□  are  selected  for  the  organization 
and  software  projects  according 
to  a  documented  procedure. 
(L5-26,  A5) 

□  are  acquired  for  the  organization 
and  software  projects  according 
to  a  documented  procedure. 
(L5-26,  A5) 

Technologies  with 
projected  expenses 
above  a  predefined 
level 

have  management  approval.  (LS-26, 
A5,  1.1) 

Technology  changes 

are  identified  by  the  group 
responsible  for  the  organization's 
technology  change  management. 
(L5-25,  A4,  2) 

Tradeoff  studies  (to 
determine  whether 
the  technology 
should  be  developed 
internally  or 
procured  externally) 

□  are  documented,  where 
appropriate.  (L5-26,  A5,  4.2) 

□  are  performed,  where 
appropriate.  (L5-26,  A5,  4.2) 

□  are  reviewed,  where  appropriate. 
(L5-26,  A5,  4.2) 
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TCM  Process  -  Exit  Criteria,  Continued 


Output*based 
exit  criteria, 
continued 


Genera]  exit 
criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  technology  change  management  process,  continued  from  the  previous 
page. 


T 

Output 

State 

References 

Uncertainty  in  the 
estimates  of  benefits 
of  (a  new 
technology’s) 
broader  use  in  the 
organization  (based 
on  the  results  of  the 
pilot  efforts  for 
improving 
technology) 

is  assessed.  (L5-28,  A6,  6.2) 

Uncertainty  in  the 
estimates  of  impacts 
of  (a  new 
technology’s) 
broader  use  in  the 
organization  (based 
on  the  results  of  the 
pilot  efforts  for 
improving 
technology) 

is  assessed.  (LS-28,  A6,  6.2) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  technology  change  management  process. 


T 

Condition 

References 

Senior  management  allocates  resources  for  technology 
change  management  activities.  (L5-19,  C3,  2) 

Senior  management  coordinates  requirements  and  issues  for 
technology  change  management  at  all  appropriate  levels  of 
the  organization.  (L5-20,  C3,  4.1) 

Senior  management  coordinates  with  the  organization's 
managers  to  secure  the  managers'  and  staffs  support  and 
participation.  (L5-20,  C3,  4.2) 
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TCM  Process  -  Exit  Criteria,  continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  technology  change  management  process,  continued  frcm  the  previous 
page. 


T 

Condition 

References 

The  group  responsible  for  the  organization's  technology 
change  management  activities  coordinates  and  helps  to 
(L5-20,  Abl,  2): 

□  explore  potential  areas  for  applying  new  technology; 

□  select  and  plan  for  new  technologies; 

□  acquire,  install,  and  customize  new  technologies; 

□  communicate  and  coordinate  with  related  research  and 
development  activities  within  the  organization;  and 

□  communicate  with  the  technology  suppliers  on  problems 
and  enhancements. 

The  group  responsible  for  the  organization's  technology 
change  management  activities  solicits  suggestions  for 
technology  changes.  (L5-24,  A2,  1) 

Systematic  efforts  are  made  to  maintain  awareness  of  leading 
relevant  technical  work  and  trends  of  new  technologies. 
(L5-25,  A2,  2.2) 

Systematic  efforts  are  made  to  review  the  technologies  used 
externally  and  to  compare  these  technologies  to  those  used 
within  the  organization.  (L5-25,  A2,  2.3) 

The  group  responsible  for  the  organization's  technology 
change  management  activities  evaluates  new  technologies  to 
determine  their  applicability  to  the  organization's  and 
projects'  cunent  and  future  needs.  (L5-25,  A2,  3) 

Software  managers  and  technical  staff  are  kept  informed  of 
new  technologies.  (L5-25,  A3) 

The  group  responsible  for  the  organization's  technology 
change  management  systematically  analyzes  the 
organization's  standard  software  process  to  identify  areas 
that  need  or  could  benefit  from  new  technology.  (L5-25, 
A4) 

□  This  group  identifies  helpful  technology  changes  and 
determines  the  economics  of  those  changes.  (L5-25,  A4, 
2) 

Preliminary  cost/benefit  analyses  are  performed  for  the 
potential  technology  changes.  (L5-26,  A5,  2) 

Continued  on  next  page 
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TCM  Process  -  Exit  Criteria,  Continued 


General  exit 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  techno  jgy  change  management  process,  continued  from  the  previous 
page. 


T 

Condition 

References 

Predefined  and  approved  selection  criteria  are  used  to 
identify  the  highest  potential  benefits  (when  selecting  and 
acquiring  technologies).  (L5-26,  AS,  3) 

Pilot  efforts  for  improving  technology  are  conducted,  where 
appropriate,  before  a  new  technology  is  introduced  into 
normal  practice.  (L5-27,  A6) 

□  These  pilot  efforts  are  conducted  to  determine  the 
feasibility  and  economics  of  untried  or  advanced 
technologies.  (L5-27,  A6,  1) 

□  The  group  responsible  for  technology  change 
management  activities  provides  consultation  and 
assistance  to  the  project  implementing  the  pilot  effort. 
(L5-27,  A6,  4) 

□  The  pilot  effort  is  performed  in  an  environment  that  is 
relevant  to  the  development  or  maintenance 
environment.  (L5-27,  A6,  5) 

The  organization's  activities  for  technology  change 
management  are  reviewed  with  senior  management  on  a 
periodic  basis.  (L5-29,  VI) 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  technology  change 
management  and  reports  the  results.  (L5-29,  V2) 
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TCM  Process  •  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  technology 
change  management  process. 


Review  or  Audit 

Review 

Participants 

References 

Senior  management  helps  to  establish 
policies  for  technology  change 
management  and  reviews  and  approves 
these  policies.  (L5-19,  C3,  1) 

Senior 

management 

The  organizational  plan  for  technology 
change  management  undergoes  peer 
review.  (L5-24,  Al,  5) 

Not  specified  in 
CMM 

The  organizational  plan  for  technology 
change  management  is  reviewed  by  the 
affected  managers.  (LS-24,  Al,  6) 

Affected 

managers 

Systematic  efforts  are  made  to  review  the 
technologies  used  externally  and  to 
compare  these  technologies  to  those  used 
within  the  organization.  (L5-25,  A2,  2.3) 

Group 

responsible  for 
the 

organization's 

technology 

change 

management 

activities 

Areas  where  new  technologies  have  been 
used  successfully  are  identified,  and  data 
and  documentation  of  experience  with 
using  them  are  collected  and  reviewed. 
(L5-25,  A2,  2.4) 

Group 

responsible  for 
the 

organization's 

technology 

change 

management 

activities 

Where  appropriate,  tradeoff  studies  are 
performed,  reviewed,  and  documented  to 
determine  whether  the  technology  should 
be  developed  internally  or  procured 
externally.  (L5-26,  A5,  4.2) 

Not  specified  in 
CMM 

The  requirements  and  plans  (for  selected 
technology  changes)  are  reviewed  by  the 
managers  of  the  affected  groups  and  the 
group  responsible  for  technology  change 
management  activities.  (L5-26,  A5, 4.4) 

— . .  '  - - - -  - - - 

Managers  of 
the  affected 
groups 

Group 

responsible  for 

technology 

change 

management 

activities 
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TCM  Process  -  Reviews  and  Audits,  Continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  technology 
change  management  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

The  plan  for  conducting  the  pilot  effort  is 
reviewed  and  approved  by  the  managers  of 
the  affected  groups.  (LS-27,  A6,  3) 

Managers  of 
the  affected 
groups 

The  organization's  activities  for  technology 

change  management  are  reviewed  with 

senior  management  on  a  periodic  basis. 

(L5-29,  VI) 

These  reviews: 

□  Summarize  the  activities  for 
technology  change  management. 

□  Identify  needed  strategy  changes. 

□  Result  in  the  resolution  of  issues 

□  Result  in  the  approval  of  revisions  to 
the  plans  for  technology  change 
management,  as  appropriate. 

Senior 

management 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  technology  change 
management  and  reports  the  results.  (LS- 
29,  V2) 

At  a  minimum,  the  reviews  and/or  audits 
verify; 

□  The  plans  for  technology  change 
management. 

□  The  process  for  selecting,  procuring, 
and  installing  new  technologies. 

Software 

quality 

assurance 

group 
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TCM  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


There  are  no  work  products  that  are  recommended  to  be  managed  and  controlled 
during  the  technology  change  management  process. 
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TCM  Process  -  Measurements 


Measurements 


The  table  below  lists  the  measurements  recommended  for  the  technology  change 
management  process. 


D 

Measurements 

References 

■ 

Data  of  experience  with  using  (new  technologies  that  have 
been  used  successfully).  (L5-25,  A2,  2.4) 

Measurements  to  determine  the  status  of  the  organization's 
activities  for  technology  change  management.  (L5-28,  Ml) 

Examples  of  measurements  include: 

□  The  overall  technology  change  activity,  including 
number,  type,  and  size  of  changes. 

□  The  effect  of  implementing  the  technology  change, 
compared  to  the  goals. 
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TCM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  the  activities  in  the  technology  change  management  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


T 

Documented  Procedure(s) 

References 

Technologies  are  selected  and  acquired  for  the  organization 
and  software  projects  according  to  a  documented  procedure. 
(L5-26,  A5) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

Appropriate  new  technologies  are  incorporated  into  the 
organization's  standard  software  process  according  to  a 
documented  procedure.  (L5-28,  A7) 

Appropriate  new  technologies  are  incorporated  into  the 
projects'  defined  software  processes  according  to  a 
documented  procedure.  (L5-28,  A8) 
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TCM  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  technology  change 
management  process. 


T 

Training 

References 

Members  of  the  group  responsible  for  the  organization's 
technology  change  management  activities  receive  required 
training  to  perform  these  activities.  (L5-23,  Ab5) 
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TCM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  technology  change 
management  process. 


Tools 

References 

Tools  to  support  technology  change  management  are  made 
available.  (L5-21,  Ab2,  2) 

Examples  of  support  tools  include: 

□  workstations, 

□  datab'  e  programs,  and 

□  subscriptions  to  on-line  technology  databases. 
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Process  Change  Management  (PCM)  Process 
PCM  Process  -  Overview 


PCM  process 
purpose 


PCM  process 
description 


The  purpose  of  Process  Change  Management  is  to  continually  improve  the 
software  processes  used  in  the  organization  with  the  intent  of  improving  software 
quality,  increasing  productivity,  and  decreasing  the  cycle  time  for  product 
development.  (L5-31) 


Process  Change  Management  involves  defining  process  improvement  goals  and, 
with  senior  management  sponsorship,  proactively  and  systematically  identifying, 
evaluating,  and  implementing  improvements  to  ^e  organization's  standard  software 
process  and  the  projects'  defined  software  processes  on  a  continuous  basis. 

Training  and  incentive  programs  are  established  to  enable  and  encourage  everyone 
in  the  organization  to  participate  in  process  improvement  activities.  Improvement 
opportunities  are  identified  and  evaluated  for  ^tential  payback  to  the 
organization.  Pilot  efforts  are  performed  to  assess  process  changes  before  they  are 
incorporated  into  normal  practice. 

When  software  process  improvements  are  approved  for  normal  practice,  the 
organization's  standard  software  process  and  the  projects'  defin^  software 
processes  are  revised  as  appropriate.  The  practices  for  revising  the  organization's 
standard  software  process  are  found  in  the  Organization  Process  Definition  key 
process  area,  and  ^e  practices  for  revising  the  projects'  defined  software  processes 
are  found  in  the  Integrated  Software  Management  key  process  area.  (LS'31) 
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PCM  Process  -  Overview,  continued 


Section 

overview 


The  table  below  contains  a  description  and  the  location  of  each  checklist  for  this 
key  process  area. 


Checklist 

Description 

Page 

Roles 

List  of  roles  participating  in  process 
activities. 

L5-Process-79 

Entry  Criteria 

Description  of  when  the  process  can  start. 

L5'Process-85 

Inputs 

Description  of  the  woric  products  used  by 
the  process. 

L5-Pror -38-87 

Activities 

Description  of  the  activities  of  the 
process. 

L5-Process-88 

Outputs 

Description  of  the  work  products 
produced  by  the  process. 

L5-Process-91 

Exit  Criteria 

Description  of  when  the  process  is 
complete. 

L5-Process-95 

Reviews  and 
Audits 

List  of  reviews  and  audits. 

L5-Process-104 

Work  Products 
Managed  and 
Controlled 

List  of  work  products  to  be  managed  and 
controlled. 

L5-Process-107 

Measurements 

Description  of  process  measurements. 

L5-Process-108 

Documented 

Procedures 

List  of  the  activities  to  be  completed 
according  to  a  documented  procedure. 

L5-Process-109 

Training 

List  of  training. 

L5-Process-110 

Tools 

List  of  tools. 

L5-Process-lll 
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PCM  Process  -  Roles 


Roles  The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 

process  change  management  process. 


T 

Role 

Activities  Participated  in... 

Reference 

Administrative 

personnel 

Administrative  personnel  are  included  in 
oversight  and  review  of  the  software 
process  improvement  activities.  (L5-38, 

A4.  6.2) 

Experienced 
individuals 
who  have 
expertise  in 
defining  and 
analyzing 
software 
processes 

Experienced  individuals  who  have 
expertise  in  defining  and  analyzing 
software  processes  are  available  to  help  the 
organization  in  its  process  improvement 
activities.  (L5-34,  Abl,  2) 
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PCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
process  change  management  process,  continued  from  the  previous  page. 


T 

Role 

Activities  Participated  in... 

Reference 

Group 

responsible  for 
the 

organization’s 

software 

process 

activities  (e.g., 

software 

engineering 

process 

group) 

□  The  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  coordinates  the 
software  process  improvement 
activities.  {L5-36,  A2) 

□  The  group  responsible  for  the 

organization's  software  process 

activities  (e.g.,  software 

engineering  process  group): 

□  Defines  organizational  goals 
and  measurement  plans  for 
software  process  performance. 

□  Reviews  the  organizational 
goals  for  process  performance 
with  senior  management  for 
their  endorsement. 

□  Participates  in  the  effort  to 
define  the  organization's 
training  needs  for  process 
improvement  and  supports  the 
development  and  presentation 
of  training  course  materials. 

□  Defines  and  maintains  the 
procedures  for  handling 
process  improvement 
proposals. 

□  Reviews  software  process 
improvement  proposals  and 
coordinates  the  actions  for 
these  proposals. 

□  Tracks  status,  accomplishments, 
and  participation  in  the  process 
improvement  activities  and 
periodically  reports  the  results 
to  senior  management. 

□  Coordinates  and  tracks  changes 
to  the  organization's  standard 
software  process. 

□  Defines,  establishes,  and 
maintains  the  process 
improvement  records. 
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PCM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
process  change  management  process,  continued  from  the  previous  page. 


T 

Role 

Activities  Participated  in... 

Reference 

Group  that 
defines  and 
maintains  the 
affected 
process 
descriptions 

The  plans  (for  process  improvement  team 
activities)  are  approved  by  the  managers  of 
the  affected  groups  and  the  group  that 
defines  and  maintains  the  affected  process 
descriptions.  (L5-41,  A6,  3) 

Individuals 
responsible  for 
implementing 
the  software 
processes 

The  strategy  for  collecting  data  to  measure 
and  track  the  change  in  software  process 
performance  is  agreed  to  by  the 
individuals  responsible  for  implementing 
the  software  processes  affected  by  the 
change.  (L5-43,  A8,  2.i) 

Management 

Software  process  changes  that  are  judged  to 
have  a  major  impact  on  product  quality  or 
productivity  or  that  will  significantly  alter 
satisfaction  of  the  customer  and  end  users 
are  reviewed  and  approved  by  appropriate 
management  before  they  are  implemented. 
(L5-41,  A5,  9) 

Managers 

□  All  of  the  organization's  staff  and 
managers  are  expected  to  participate  in 
improving  the  software  processes.  (L5- 
32,  Cl,  3) 

□  The  software  process  improvement  plan 
is  reviewed  by  the  affected  managers. 
{L5-37,  A3,  3) 

□  The  plans  (for  process  improvement 
team  activities)  are  approved  by  the 
managers  of  the  affected  groups  and 
the  group  that  defines  and  maintains 
the  affected  process  descriptions.  (L5- 
41,  A6,  3) 

Managers  of 
software- 
related  groups 

The  managers  and  technical  staff  of  the 
software  engineering  group  and  other 
software-related  groups  receive  required 
training  in  software  process  improvement. 
(L5-34,  Ab3) 

Managers  of 
the  software 
engineering 
group 

The  managers  and  technical  staff  of  the 
software  engineering  group  and  other 
software-related  groups  receive  required 
training  in  software  process  improvement. 
(L5-34,  Ab3) 
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PCM  Process  -  Roles,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
process  change  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Members  of 
the 

organization 

□  A  software  process  improvement 
program  is  established  which  empowers 
the  members  of  the  organization  to 
improve  the  processes  of  the 
organization.  (L5-35,  Al) 

□  Members  of  the  organization  actively 
participate  in  teams  to  develop  software 
process  improvements  for  assigned 
process  areas.  (L5-41,  A6) 

Senior 

management 

□  Senior  management  sponsors  the 
organization's  activities  for  software 
process  improvement.  (L5-32,  Cl) 

□  Senior  management: 

□  Establishes  the  organization's 
long-term  goals  and  plans  for 
process  improvement. 

□  Allocates  resources  for  process 
improvement  activities. 

□  Coordinates  with  the  software 
managers  to  ensure  they  have 
reasonable,  yet  aggressive, 
process  improvement  goals  and 
effective  process  improvement 
plans  to  meet  these  goals. 

□  Monitors  process  improvement 
performance  against  goals. 

□  Maintains  a  consistent  priority 
focus  on  process  improvement 
in  the  face  of  product  crises. 

□  Ensures  that  process 
improvement  issues  are 
promptly  resolved. 

□  Rewards  employee  participation 
in  the  process  improvement 
activities. 

□  Senior  management  receives  required 
training  in  software  process 
improvement.  (L5-35,  Ab4) 

Role  continued  on  next  page 
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PCM  Process  -  Rotes,  Continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
process  change  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Senior 

management, 

continued 

□  The  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  reviews  the 
organizational  goals  for  process 
performance  with  senior  management 
for  their  endorsement.  (L5-36,  A2,  2) 

□  The  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group)  tracks  status, 
accomplishments,  and  participation  in 
the  process  improvement  activities  and 
periodically  reports  the  results  to  senior 
management.  (LS-36,  A2,  6) 

□  The  activities  for  software  process 
improvement  are  reviewed  with  senior 
management  on  a  periodic  basis.  (LS- 
46,  VI) 

Software 

managers 

□  Senior  management  coordinates  with 
the  software  managers  to  ensure  they 
have  reasonable,  yet  aggressive,  process 
improvement  goals  and  effective 
process  improvement  plans  to  meet 
these  goals.  (L5-33,  C2,  3) 

Q  Software  managers  receive  required 
training  in  software  process 
improvement.  (L5-34,  Ab2) 

□  Software  managers  and  technical  staff 
receive  feedback  on  the  status  and 
results  of  the  software  process 
improvement  activities  on  an  event- 
driven  basis.  (L5-44,  A 10) 

Software 
quality 
assurance 
(SQA)  group 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  process  improvement 
and  reports  the  results.  (L5-46,  V2) 
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PCM  Process  -  Roles,  continued 


Roles, 

continued 


The  table  below  lists  the  roles  and  the  activities  in  which  they  participate  in  the 
process  change  management  process,  continued  from  the  previous  page. 


Role 

Activities  Participated  in... 

Reference 

Staff 

□  All  of  the  organization's  staff  and 
managers  are  expected  to  participate  in 
improving  the  software  processes.  (L5- 
32,  Cl,  3) 

□  Software  managers  and  technical  staff 
receive  feedback  on  the  status  and 
results  of  the  software  process 
improvement  activities  on  an  event- 
driven  basis.  (L5-44,  A 10) 

Submitters  of 
the  software 
process 
improvement 
proposals 

Submitters  of  the  software  process 
improvement  proposals  receive:  (LS-41, 
A5,  11) 

□  Prompt  acknowledgment  of  their 
proposals. 

□  Notification  of  the  disposition  of  their 
proposals. 

Team 

responsible  for 
implementa¬ 
tion  (of 
software 
process 
improvement 
actions) 

Software  process  improvement  actions  that 
require  a  substantial  effort  are  assigned  to  a 
team  responsible  for  implementation. 
(L5-40,  A5,  6) 

Technical  staff 
of  software- 
related  groups 

The  managers  and  technical  staff  of  the 
software  engineering  group  and  other 
software-related  groups  receive  required 
training  in  software  process  improvement. 
(L5-34,  Ab3) 

Technical  staff 
of  the  software 
engineering 
group 

The  managers  and  technical  staff  of  the 
software  engineering  group  and  other 
software-related  groups  receive  required 
training  in  software  process  improvement. 
(L5-34,  Ab3) 
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PCM  Process  -  Entry  Criteria 


Input'based 
entry  criteria 


General  entry 
criteria 


The  CMM  recommends  that  inputs  satisfy  the  states  described  in  the  table  below 
before  entering  the  process  change  management  process. 


Input 

State 

References 

Organizational  goals 
for  software  process 
improvement 

□  are  quantitative.  (L5-32,  Cl,  1) 

□  are  measurable.  (L5-32,  Cl,  1) 

Software  process 

improvement 

proposal 

is  submitted.  (L5-39,  A5,  1) 

The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  process  change  management  process. 


T 

Condition 

References 

The  organization  follows  a  written  policy  for  implementing 
software  process  improvements.  (L5-32,  Cl) 

[Refer  to  Level  5  Policies  for  additional  information 
regarding  PCM  policy.] 

Senior  management  sponsors  the  organization's  activities 
for  software  process  improvement,  (L5-32,  C2) 

Adequate  resources  and  funding  are  provided  for  software 
process  improvement  activities.  (L5-33,  Abl) 

Resources  are  allocated  to:  (L5-33,  Abl,  1) 

□  Lead,  guide,  and  support  the  process  improvement 
activities. 

□  Maintain  the  process  improvement  records. 

□  Develop,  control,  and  disseminate  process  changes. 

□  Establish  and  operate  the  administrative  and  human 
resources  functions  to  conduct  the  communications, 
motivation,  and  recognition  activities  needed  to  maintain 
a  high  level  of  employee  participation. 

Experienced  individuals  who  have  expertise  in  defining 
and  analyzing  software  processes  are  available  to  help  the 
organization  in  its  process  improvement  activities.  (L5-34, 
Abl,  2) 

Tools  to  support  process  improvement  are  made  available. 
(L5-34,  Abl,  3) 

Software  managers  receive  required  training  in  software 
process  improvement.  (L5-34,  Ab2) 

Continued  on  next  page 
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PCM  Process  -  Entry  Criteria,  Continued 


General  entry 

criteria, 

continued 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
before  entering  the  process  change  management  process,  continued  from  the 
previous  page. 


T 

Condition 

References 

The  managers  and  technical  staff  of  the  software 
engineering  group  and  other  software-related  groups 
receive  required  training  in  software  process  improvement. 
(L5-34,  Ab3) 

Senior  management  receives  required  training  in  software 
process  improvement.  {L5-35,  Ab4) 
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PCM  Process  -  Inputs 


Inputs 


The  table  below  lists  the  inputs  to  the  process  change  management  process. 


T 

Input 

Org.  Input 

References 

Customer  satisfaction  indicators.  (L5-37, 
A3,  1.2) 

Expected  needs.  (L5-43,  A8,  4) 

Long-term  goals  for  software  process 
improvement.  (L5-38,  A4,  3) 

Long-term  goals  for  software  process 
performance.  (L5-38,  A4,  3) 

Organization's  business  plans.  (L5-37,  A3, 
1.1) 

Organization's  strategic  operating  plans. 
(L5-37,  A3,  1.1) 

Organizational  goals  for  software  process 
improvement.  (L5-32,  Cl,  1) 

Plan  for  software  process  improvement. 
(L5.37,  A3) 

[Refer  to  Level  5  Standards  for  additional 
information  regarding  this  plan.) 

Process  improvement  goals.  (L5-33,  C2,  4) 

Process  improvement  records.  (L5,  33, 

Abl,  1.2) 

Short-term  goals  for  software  process 
improvement.  (L5-38,  A4,  3) 

Short-term  goals  for  software  process 
performance.  (L5-38,  A4,  3) 

Software  process  improvement  issues.  (L5- 
33,  C2,  6) 

Software  process  improvement  proposal. 
(L5-36,  A2,  4) 
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PCM  Process  -  Activities 


Activities 


The  table  below  lists  the  recommended  activities  for  the  process  change 
management  process. 


Activities 

References 

A  software  process  improvement  program  is  established 
which  empowers  the  members  of  the  organization  to 
improve  the  processes  of  the  organization.  (L5-35,  Al) 

The  group  responsible  for  the  organization's  software 
process  activities  (e.g.,  software  engineering  process 
group)  coordinates  the  software  process  improvement 
activities.  (L5-36,  A2) 

The  organization  develops  and  maintains  a  plan  for  software 
process  improvement  according  to  a  documented  procedure. 
(L5-37,  A3) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

The  software  process  improvement  activities  are  performed 
in  accordance  with  the  software  process  improvement  plan. 
(L5-38,  A4) 

Software  process  improvement  proposals  are  handled 
according  to  a  documented  procedure,  (L5-39,  A5) 

(Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

Members  of  the  organization  actively  participate  in  teams  to 
develop  software  process  improvements  for  assigned  process 
areas.  (L5-41,  A6) 

□  Each  of  these  process  improvement  teams  is  funded  and 
the  activities  are  planned  and  scheduled. 

□  Goals  are  established  for  each  process  improvement 
effort;  where  possible,  these  goals  are  defined 
quantitatively. 

□  The  plans  are  approved  by  the  managers  of  the  affected 
groups  and  the  group  that  defines  and  maintains  the 
affected  process  descriptions. 
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PCM  Process  -  Activities,  Continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  process  change 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

Where  appropriate,  the  software  process  improvements  are 
installed  on  a  pilot  basis  to  determine  their  benefits  and 
effectiveness  before  they  are  introduced  into  normal 
practice.  {L5-42,  A7) 

□  Adjustments  to  the  proposed  process  improvement  are 
made  and  documented  during  the  pilot  effort  to 
optimize  its  implementation. 

□  Lessons  learned  and  problems  encountered  are 
documented. 

□  The  benefits,  risks,  and  impacts  of  the  process 
improvement's  broader  use  in  the  organization  are 
estimated,  and  the  uncertainty  in  these  estimates  is 
assessed. 

□  A  decision  is  made  whether  to  terminate  the  effort, 
proceed  with  broad-scale  implementation  of  the 
improvement,  or  replan  and  continue  the  pilot  effort. 

When  the  decision  is  made  to  transfer  a  software  process 
improvement  into  normal  practice,  the  improvement  is 
implemented  according  to  a  documented  procedure.  (L5- 
42.  A8) 

[Refer  to  Level  .1  Procedure  Checklists  for  additional 
information.] 

Records  of  software  process  improvement  activities  are 

maintained.  (L5-43,  A9) 

□  Information  about  the  initiation,  status,  and 
implementation  of  software  process  improvement 
proposals  is  maintained. 

□  Ready  access  is  provided  to  the  software  process 
improvement  records. 

□  Historical  data  are  maintained  and  reports  are  produced 
on  software  process  improvements. 

Software  managers  and  technical  staff  receive  feedback  on 
the  status  and  results  of  the  software  process  improvement 
activities  on  an  event-driven  basis.  (L5-44,  AlO) 

Measurements  are  made  and  used  to  determine  the  status  of 
the  software  process  improvement  activities.  (L5-45,  Ml) 

Continued  on  next  page 


CMU/SEI>94-HB-1 


L5>Proce«s«89 


PCM  Process  -  Activities,  continued 


Activities, 

continued 


The  table  below  lists  the  recommended  activities  for  the  process  change 
management  process,  continued  from  the  previous  page. 


V 

Activities 

References 

The  activities  for  software  process  improvement  are  reviewed 
with  senior  management  on  a  periodic  basis.  (L5-46,  VI) 

[Refer  to  PCM  Process  Reviews  and  Audits  for  additional 
information.] 

The  software  quality  assurance  group  reviews  and/or  audits 
the  activities  and  work  products  for  software  process 
improvement  and  reports  the  results.  (L5-46,  V2) 

[Refer  to  PCM  Process  Reviews  and  Audits  for  additional 
information.] 
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PCM  Process  -  Outputs 


Outputs 


The  table  below  lists  the  recommended  outputs  produced  by  the  process  change 
management  process. 


Output 

Org.  Output 

References 

Accomplishments  of  the  process 
improvement  activities.  (L5-36,  A2,  6) 

Adjustments  to  the  proposed  process 
improvement.  (L5-42,  A7,  1) 

Benefits  of  each  software  process 
improvement.  (L5-40,  A5,  3) 

Change  in  software  process  performance. 
(L5^3,  A8,  2) 

Changes  to  the  organization's  standard 
software  process.  (L5-36,  A2,  7) 

Changes  to  the  projects'  defined  software 
processes.  (L5-47,  V2,  4) 

Decision  rationale  (for  deciding  whether  to 
implement  the  software  process 
improvement  proposal).  (L5-39,  A5,  2) 

Decision  to  transfer  a  software  process 
improvement  into  normal  practice.  (LS- 
42,  A8) 

Decision  whether  to  implement  each 
software  process  improvement  proposal. 
(L5-39,  A5,  2) 

Decision  whether  to  terminate  the  (pilot) 
effort,  proceed  with  broad-scale 
implementation  of  the  improvement,  or 
replan  and  continue  the  pilot  effort.  (LS- 
42,  A7,  4) 

Expected  beneftts  of  each  software  process 
improvement  proposal.  (L5-40,  A5,  3) 

Feedback  on  the  status  and  results  of  the 
software  process  improvement  activities. 
(L5-44,  AlO) 

Focus  on  high-priority  software  process 
improvement  proposals.  (L5-40,  A5,  4.1) 

Goals  for  each  process  improvement  effort. 
(L5-41,  A6,  2) 

Highest  priority  process  areas  for 
improvement.  (L5-38,  A4,  2) 
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PCM  Process  -  Outputs,  continued 


Outputs, 

continued 


The  table  below  lists  the  recommended  outputs  produced  by  the  process  change 
management  process,  continued  from  the  previous  page. 


V 

Output 

Org.  Output 

References 

Historical  data  on  software  process 
improvements.  (L5-44,  A9,  3) 

Impacts  of  each  software  process 
improvement.  (L5-42,  A7,  3) 

Information  about  the  implementation  of 
software  process  improvement  proposals. 
(L5-44.  A9,  1) 

Information  about  the  initiation  of  software 
process  improvement  proposals.  (LS-44, 
A9.  1) 

Information  about  the  status  of  software 
process  improvement  proposals  (LS-44, 
A9.  1) 

Lessons  learned  (from  piloting  software 
process  improvements).  (L5-42,  A7,  2) 

Measurement  plans  for  software  process 
performance.  (L5-36,  A2,  1) 

Measurements  (to  determine  the  status  of 
the  software  process  improvement 
activities).  (L5-45,  Ml) 

Needed  goal  changes.  (L5-46,  VI,  3) 

Notification  of  the  disposition  of  software 
process  improvement  proposals.  (L5-41, 
A5,  11.2) 

Organization's  long-term  goals  for  process 
improvement.  (L5-33,  C2,  1) 

Organization's  long-term  plans  for  process 
improvement.  (L5-33,  C2,  1) 

Organization's  training  needs  for  process 
improvement.  (L5-36,  A2,  3) 

Organizational  goals  for  software  process 
performance.  (L5-36,  A2,  1) 

Organizational  plan  for  software  process 
improvement.  (L5-37,  A3) 

Plans  for  process  improvement  team 
activities.  (L5-41,A6,  1) 
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PCM  Process  -  Outputs,  Continued 


Outputs,  The  table  below  lists  the  recommended  outputs  produced  by  the  process  change 

conUnu^  management  process,  continued  from  the  previous  page. 


T 

Output 

Org.  Output 

References 

Priority  of  software  process  improvement 
proposals  selected  for  implementation. 
(L5-40,  A5,  4) 

Problems  encountered  (when  pilot  testing 
software  process  improvements).  (L5*42, 
A7.2) 

Process  changes.  (L5-33,  Abl,  1.3) 

Process  improvement  goals.  (L5-33,  C2,  3) 

Process  improvement  plans  to  meet  these 
(process  improvement)  goals.  (L5-33,  C2, 
3) 

Process  measurements.  (L5-47,  V2,  3) 

Prompt  acknowledgment  of  submitted 
software  process  improvement  proposals. 
(L5-41.  A5,  11.1) 

Records  of  software  process  improvement. 
(L5-36,  A2,  8) 

Reports  on  software  process  improvements. 
(L5-44,  A9,  3) 

Results  (of  software  quality  assurance 
group  reviews  and/or  audits  of  the  activities 
and  work  products  for  software  process 
improvement).  (L5-46,  V2) 

Results  of  tracking  status,  accomplishments, 
and  participation  in  the  process 
improvement  activities  (from  the  group 
responsible  for  the  organization’s 
software  process  activities,  e.g.,  software 
engineering  process  group).  (LS-36,  A2, 
6) 

Revisions  to  the  plan  for  software  process 
improvement.  (L5-46,  VI,  5) 

Risks  of  each  software  process 
improvement.  (L5*42,  A7,  3) 

Software  process  improvement.  (L5-42, 
A8) 
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PCM  Process  -  Outputs,  continued 


Outputs, 

continu^ 


The  table  below  lists  the  recommended  outputs  produced  by  the  process  change 
management  process,  continued  from  the  previous  page. 


Output 

Org.  Output 

References 

Status  of  each  software  process 
improvement  proposal.  (L5-41,  A5,  7) 

Status  of  the  process  improvement 
activities.  (L5-36,  A2,  6) 

Strategy  for  collecting  data  to  measure  and 
track  the  change  in  software  process 
performance.  (L5-43,  A8,  2) 

Summary  of  the  major  software  process 
improvement  activities.  (L5-44,  A 10,  1) 

Summary  status  of  the  software  process 
improvement  proposals  that  are  submitted, 
open,  and  completed.  (L5-44,  AlO,  3) 

Training  course  materials.  (L5-36,  A2,  3) 

Training  courses.  (L5-43,  A8,  3) 

Uncertainty  in  the  estimate  of  the  benefits 
of  each  software  process  improvement 
proposal.  (L5-42,  A7,  3) 

Uncertainty  in  the  estimate  of  the  impacts 
of  each  software  process  improvement 
proposal.  (L5-42,  A7,  3) 

Uncertainty  in  the  estimate  of  the  risks  of 
each  software  process  improvement 
proposal.  (L5-42,  A7,  3) 
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PCM  Process  -  Exit  Criteria 


Output'based 
exit  criteria 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process. 


T 

Output 

State 

References 

Accomplishments  of 
the  process 
improvement 
activities 

are  tracked  by  the  group  responsible 
for  the  organization's  softvrare 
process  activities,  e.g.,  software 
engineering  process  group.  (LS-36, 
A2.6) 

Adjustments  to  the 
proposed  process 
improvement 

Q  are  made  during  the  pilot  effort 
to  optimize  its  implementation. 
(L5-42,  A7,  1) 

□  are  documented  during  the  pilot 
effort  to  optimize  its 
implementation.  (L5-42,  A7,  1) 

Benefits  of  each 
software  process 
improvement 

□  are  determined,  where 
appropriate,  (by  installing  the 
improvements)  on  a  pilot  basis 
before  they  are  introduced  into 
normal  practice.  (L5-42,  A7) 

□  are  estimated  (for  broader  use  in 
the  organization  based  on  pilot 
testing).  (L5-42,  A7,  3) 
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PCM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process,  continued  from  the  previous  page. 


T 

Output 

State 

References 

Changes  to  the 
organization's 
standard  software 
process  or  software 
process  changes 

□  are  coordinated  by  the  group 
responsible  for  the 
organization’s  software  process 
activities,  e.g.,  software 
engineering  process  group. 
(L5-36.  A2.  7) 

□  are  tracked  by  the  group 
responsible  for  the 
organization'.^  software  process 
acUvities,  e.g.,  software 
engineering  process  group.  LS- 
36.  A2,  7) 

□  that  are  judged  to  have  a  major 
impact  on  product  quality  or 
productivity  or  that  will 
significantly  alter  satisfaction  of 
the  customer  and  end  users  are 
reviewed  and  approved  by 
appropriate  management  before 
they  are  implemented.  (L5-41, 
A5.  9) 

□  are  incorporated  into  the 
organization's  standard  software 
process.  (L5-43,  A8,  5) 

□  are  incorporated  into  the 
projects'  defined  software 
processes.  (L5-43,  A8,  6) 

Decision  rationale 
(for  deciding  whether 
to  implement  the 
software  process 
improvement 
proposal) 

is  documented.  (L5-39,  A5,  2) 

Decision  whether  to 
implement  each 
software  process 
improvement 
proposal 

is  made.  (L5-39,  A5,  2) 
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PCM  Process  -  Exit  Criteria,  continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process,  continued  from  the  previous  page. 


T 

Output 

State 

References 

Decision  whether  to 
terminate  the  (pilot) 
effort,  proceed  with 
broad-scale 
implementation  of 
the  improvement,  or 
replan  and  continue 
the  pilot  effort 

is  made.  (L5-42,  A7,  4) 

Expected  benefits  of 
each  software  process 
improvement 
proposal 

are  determined.  (L5-40,  A5,  3) 

Feedback  on  the 
status  and  results  of 
the  software  process 
improvement 
activities 

□  is  received  by  software 
uii^nagers  and  technical  staff  on 
an  event-driven  basis.  (1.5-44, 
AlO) 

□  provides  a  summary  of  th?  major 
software  process  improvement 
activities.  (L5-44.  AlO,  1) 

Q  provides  significant  innovations 
and  actions  taken  to  address 
software  process  improvement. 
(L5-44,  AlO,  2) 

□  provides  a  summary  status  of  the 
software  process  improvement 
proposals  that  are  submitted, 
open,  and  completed.  (L5-44, 
AlO,  3) 

Focus  on  high- 
priority  software 
process  improvement 
proposals 

is  maintained.  (L5-40,  A5,  4.1) 

Goals  for  each 
process  improvement 
effort 

□  are  established.  (LS-41,  A6,  2) 

□  are  defined  quantitatively,  where 
possible.  (L5-41,  A6,  2) 

Historical  data  on 
software  process 
improvements 

are  maintained.  (L5-44,  A9,  3) 
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PCM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process,  continued  from  the  previous  page. 


Output 


References 


Impacts  of  each 
software  process 
improvement 

are  estimated  (for  broader  use  in  the 
organization  based  on  pilot  testing). 
(L5-42.  A7,  3). 

Information  about 
the  implementation 
of  software  process 
improvement 
proposals 

is  maintained.  (L5-44,  A9,  1) 

Information  about 
the  initiation  of 
software  process 
improvement 
proposals 

is  maintained.  (L5-44,  A9,  1) 

Information  about 
the  status  of  software 
process  improvement 
proposals 

is  maintained.  (L5-44,  A9,  1) 

Lessons  learned 
(from  piloting 
software  process 
improvements) 

are  documented.  (L5-42,  A7,  2) 

Measurement  plans 
for  software  process 
performance 

are  defined  by  the  group  responsible 
for  the  organization's  software 
process  activities  (e.g.,  software 
engineering  process  group).  (LS- 
36.  A2,  1) 

Measurements  (to 
determine  the  status 
of  the  software 
process  improvement 
activities) 

are  made.  (L5-45,  Ml) 
are  used.  (L5-45,  Ml) 

Needed  goal  changes 

are  identified  (during  periodic  senior 
management  reviews  of  the  activities 
for  software  process  improvement). 
(L5-46,  VI,  3) 
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PCM  Process  >  Exit  Criteria,  Continued 


Output'based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process,  continued  from  the  previous  page. 


V 

Output 

State 

References 

Notification  of  »he 
disposition  of 
software  process 
improvement 
proposals 

is  received  by  submitters  of  the 
software  process  improvement 
proposals.  (L5-41,  A5,  11.2) 

Organization's  long¬ 
term  goals  for 
process  improvement 

are  established  by  senior 
management.  (L5-33,  C2, 1) 

Organization's  long¬ 
term  plans  for 
process  improvement 

are  established  by  senior 
management.  (LS-33,  C2,  1) 

Organization's 
training  needs  for 
process  improvement 

are  defined  with  the  participation  of 
the  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software  engineering 
process  group).  (L5-36,  A2,  3) 

Organizational  goals 
for  software  process 
performance 

□  are  defined  by  the  group 
responsible  for  the 
organization's  software  process 
activities  (e.g.,  software 
engineering  process  group). 
(L5-36,  A2,  1) 

□  are  reviewed  v.’ith  senior 
management  for  their 
endorsement.  (L5-'*6,  A2,  2) 

Organizational  plan 
for  software  process 
improvement 

□  is  developed  according  to  a 
documented  procedure.  {L5-37, 
A3) 

□  is  maintained  according  to  a 
documented  procedure.  (L5-37, 
A3) 

□  undergoes  peer  review.  (L5-37, 
A3,  2) 

□  is  reviewed  by  the  affected 
managers.  (L5-37,  A3,  3) 

□  is  managed  and  controlled.  (L5- 
37,  A3,  4) 

Continued  on  next  page 
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PCM  Process  -  Exit  Criteria,  continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process,  continued  from  the  previous  page. 


>/ 

Output 

State 

References 

Plans  for  process 
improvement  team 
activities 

are  approved  by  the  managers  of  the 
affected  groups  and  the  group  that 
deflnes  and  maintains  the  affected 
process  descriptions.  (L5-41,  A6,  3) 

Priority  of  software 
process  improvement 
proposals  selected  for 
implementation 

is  determined.  (L5-40,  A5,  4) 

Problems 

encountered  (when 
pilot  testing  software 
process 

improvements) 

are  documented.  (L5-42,  A7,  2) 

Process  improvement 
goals 

are  reasonable,  yet  aggressive.  (L5- 
33.  C2.  3) 

Process  improvement 
plans  to  meet  these 
(process 

improvement)  goals 

are  effective.  (L5-33,  C2,  3) 

Prompt 

acknowledgment  of 
submitted  software 
process  improvement 
proposals 

is  received  by  submitters  of  the 
software  process  improvement 
proposals.  (L5-41,  A5,  11.1) 

Records  of  software 
process  improvement 

□  are  defined, 

□  are  established,  and 

□  are  maintained 

by  the  group  responsible  for  the 
organization's  software  process 
activities,  e.g.,  software  engineering 
process  group.  (L5-36,  A2,  8) 

□  are  readily  accessible.  (LS-44, 
A9,2) 

Reports  on  software 

process 

improvements 

are  produced.  (L5-44,  A9,  3) 

Continued  on  next  page 
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PCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process,  continued  from  the  previous  page. 


T 

Output 

State 

References 

Results  (of  software 
quality  assurance 
group  reviews  and/or 
audits  of  the  activities 
and  work  products 
for  software  process 
improvement) 

are  reported.  (L5-46,  V2) 

Results  of  tracking 
status, 

accomplishments, 
and  participation  in 
the  process 
improvement 
activities 

are  periodically  reported  to  senior 
mai.agement  (by  the  group 
responsible  for  the  organization's 
software  process  activities  e.g., 
software  engineering  process 
group).  (L5-36,  A2,  6) 

Revisions  to  the  plan 
for  software  process 
improvement 

are  approved  (during  periodic  senior 
management  reviews  of  the  activities 
for  software  process  improvement), 
as  appropriate.  (L5-46,  VI,  5) 

Risks  of  each 
software  process 
improvement 

are  estimated  (for  broader  use  in  the 
organization  based  on  pilot  testing). 
(L5-42,  A7,  3) 

Software  process 
improvement 

is  implemented  according  to  a 
documented  procedure.  (L5-42,  A8) 

Status  of  each 
software  process 
improvement 
proposal 

is  tracked.  (L5-41,  A5,  7) 

Status  of  the  process 

improvement 

activities 

is  tracked  by  the  group  responsible 
for  the  organization's  softwar 
process  activities,  e.g.,  software 
engineering  process  group.  (LS-36, 
A2,6) 

Continued  on  next  page 
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PCM  Process  -  Exit  Criteria,  Continued 


Output-based 
exit  criteria, 
continued 


The  CMM  recommends  that  outputs  satisfy  the  states  described  in  the  table  below 
to  exit  the  process  change  management  process,  continued  from  the  previous  page. 


Output 

State 

References 

Strategy  for 
collecting  data  to 
measure  and  track 
the  change  in 
software  process 
performance  (from 
transferring  a 
software  process 
improvement  into 
normal  practice) 

□  is  documented.  (L5-43,  A8,  2) 

□  is  reviewed.  (L5-43,  A8,  2) 

□  is  agreed  to  by  the  individuals 
responsible  for  implementing  the 
software  processes  affected  by 
the  change.  (LS-43,  A8,  2.1) 

Training  course 
materials 

□  development  is  supported  by  the 
group  responsible*  for  the 
organization's  software  process 
activities  (e.g.,  software 
engineering  process  group). 
(L5-36,  A2,  3) 

□  presentation  is  supported  by  the 
group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software 
engineering  process  group). 
(L5-36,  A2,  3) 

Training  courses 

are  updated  to  reflect  the  current 
software  process.  (L5-43,  A8,  3) 

Uncertainty  in  the 
estimate  of  the 
benefits  of  each 
software  process 
improvement 
proposal 

is  assessed.  (L5-42,  A7,  3) 

Uncertainty  in  the 
estimate  of  the 
impacts  of  each 
softv/are  process 
improvement 
proposal 

is  assessed.  (L5-42,  A7,  3) 

Uncertainty  in  the 
estimate  of  the  risks 
of  each  software 
process  improvement 
proposal 

is  assessed.  (L5-42,  A7,  3) 

Continued  on  next  page 
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PCM  Process  -  Exit  Criteria,  Continued 


General  exit 
criteria 


The  CMM  recommends  that  the  conditions  described  in  the  table  below  be  satisfied 
to  exit  the  process  change  management  process. 


Condition 

References 

The  organization  has  quantitative,  measurable  goals  for 
software  process  improvement  and  tracks  performance 
against  these  goals.  (L5-32,  Cl,  1) 

A  software  process  improvement  program  is  established 
which  empowers  the  members  of  the  organization  to 
improve  the  processes  of  the  organization.  (L5-35,  Al) 

The  group  responsible  for  the  organization's  software 
process  activities  (e.g.,  software  engineering  process 
group)  coordinates  the  software  process  improvement 
activities.  (L5-36,  A2) 

The  software  process  improvement  activities  are  performed 
in  accordance  with  the  software  process  improvement  plan. 
(L5-38,  A4) 

Software  process  improvement  proposals  are  handled 
according  to  a  documented  procedure.  (L5-39,  A5) 

Each  software  process  improvement  proposal  is  evaluated;  a 
decision  is  made  whether  to  implement  the  proposal,  and  the 
decision  rationale  is  documented.  (L5-39,  A5,  2) 

Software  process  improvement  proposals  for  which  the 
response  has  been  unusually  long  are  identified  and  acted 
upon.  {L5-41,  A5,  8) 

Each  of  the  process  improvement  teams  is  funded  and  the 
activities  are  planned  and  scheduled.  (L5-41,  A6,  1) 

Training  courses  are  updated  to  reflect  the  current  software 
process,  and  training  is  provided  before  installing  the 
process  change  for  general  use.  (L5-43,  A8,  3) 

Consultation  support,  appropriate  to  the  expected  needs,  is 
established  before  installing  the  process  change  for  broad- 
scale  use  and  is  continued  as  needed.  (L5-43,  A8,  4) 
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PCM  Process  •  Reviews  and  Audits 


Reviews  and 
audits 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  process  change 
management  process. 


Review  or  Audit 

Review 

Participants 

References 

The  group  responsible  for  the 
organization's  software  process  activities 
(e.g.,  software  engineering  process 
group)  reviews  the  organizational  goals  for 
process  performance  with  senior 
management  for  their  endorsement.  (L5- 
36,  A2,  2) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group) 

Senior 

management 

The  group  responsible  for  the 
organization's  software  process  activities 
(e.g.,  software  engineering  process 
group)  reviews  software  process 
improvement  proposals  and  coordinates 
the  actions  for  these  proposals.  (L5-36, 

A2.  5) 

Group 

responsible  for 
the 

organization's 

software 

process 

activities  (e.g., 

software 

engineering 

process  group) 

The  software  process  improvement  plan 
undergoes  peer  review.,  (L5-37,  A3,  2) 

Not  specified  in 
theCMM 

The  software  process  improvement  plan  is 
reviewed  by  the  affected  managers.  (LS- 
37,  A3,  3) 

Affected 

managers 

Software  process  changes  that  are  judged 
to  have  a  major  impact  on  product  quality 
or  productivity  or  that  will  significantly 
alter  satisfaction  of  the  customer  and  end 
users  are  reviewed  and  approved  by 
appropriate  management  before  they  are 
implemented.  (L5-41,  A5,  9) 

Management 

Completed  software  process  improvement 
actions  are  reviewed,  verified,  and  approved 
before  they  are  closed.  (L5-41,  A5,  10) 

Not  specified  in 
theCMM 

The  strategy  for  collecting  data  to  measure 
and  track  the  change  in  software  process 
performance  is  documented,  reviewed,  and 
agreed  to.  (L5-43,  A8,  2) 

Not  specified  in 
theCMM 

Continued  on  next  page 


L5-Proces8>104 


CMU/SEI-94-HB-1 


PCM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  •‘^able  below  lists  the  recommended  reviews  and  audits  for  the  process  change 
management  process,  continued  from  the  previous  page. 


Review  or  Audit 

Review 

Participants 

References 

The  activities  for  software  process 

improvement  are  reviewed  with  senior 

management  on  a  periodic  basis.  (L5-46, 
VI) 

These  reviews  are  held  to: 

□  Summarize  participation  in  the  process 
improvement  activities. 

□  Assess  process  performance. 

□  Identify  needed  goal  changes. 

□  Resolve  issues. 

□  Approve  revisions  to  the  software 
process  improvement  plan  as 
appropriate. 

Senior 

management 

Continued  on  next  page 
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PCM  Process  -  Reviews  and  Audits,  continued 


Reviews  and 

audits, 

continued 


The  table  below  lists  the  recommended  reviews  and  audits  for  the  process  change 
management  process,  continued  from  the  previous  page. 


T 

Review  or  Audit 

Review 

Participants 

References 

The  software  quality  assurance  group 
reviews  and/or  audits  the  activities  and  work 
products  for  software  process  improvement 
and  reports  the  results.  (L5-46,  V2) 

At  a  minimum,  the  reviews  and/or  audits 
verify: 

□  The  preparation  of  the  organization's 
software  process  improvement  plan. 

□  The  process  of  initiating,  submitting, 
reviewing,  approving,  and  planning 
implementation  of  software  process 
improvement  proposals. 

□  The  degree  to  which  the  process 
measurements  conform  to  the  software 
process  descriptions  and  reflect  actual 
performance. 

□  The  process  for  documenting, 
reviewing,  approving,  controlling,  and 
disseminating  changes  to  the 
organization's  standard  software 
process  and  projects'  defined  software 
processes. 

□  The  degree  to  which  software  process 
improvement  activities  are  consistently 
measured  and  tracked. 

□  The  degree  to  which  actual  software 
process  improvement  performance 
achieves  the  plans  and  goals. 

Software 

quality 

assurance 

group 
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PCM  Process  -  Work  Products  Managed  and  Controlled 


Work  products 
managed  and 
controlled 


The  table  below  lists  the  work  products  recommended  to  be  managed  and 
controlled  during  the  process  change  management  process. 


T 

Work  Products  Managed  and  Controlled 

References 

Software  process  improvement  plan.  (L5-37,  A3,  4) 
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PCM  Process  -  Measurements 


Measurements  The  table  below  lists  the  measurements  recommended  for  the  process  change 
management  process. 

Measurements  References 

Measurements  to  determine  the  status  of  the  software  process 
improvement  activities.  (L5-45,  Ml) 

Examples  of  measurements  include: 

□  The  number  of  software  process  improvement  proposals 
submitted  and  implemented  for  each  process  area. 

□  The  number  of  software  process  improvement  proposals 
submitted  by  each  of  the  projects,  groups,  and 
departments. 

□  The  number  and  types  of  awards  and  recognitions 
received  by  each  of  the  projects,  groups,  and 
departments. 

□  The  response  time  for  handling  software  process 
improvement  proposals. 

□  The  percentage  of  software  process  improvement 
proposals  accepted  per  reporting  period. 

□  The  overall  change  activity,  including  number,  type,  and 
size  of  changes. 

□  The  effect  of  implementing  each  process  improvement 
compared  to  its  defined  goals. 

□  Overall  performance  of  the  organization’s  and  project’s 
processes,  including  effectiveness,  quality,  and 
productivity  compared  to  their  defined  goals. 

□  Overall  productivity  and  software  quality  trends  for  each 
project. 

□  Process  measurements  that  relate  to  the  indicators  of  the 
customer’s  satisfaction. 
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PCM  Process  -  Documented  Procedures 


Documented 

procedures 


The  table  below  lists  activities  in  the  process  change  management  process 
recommended  to  be  performed  according  to  a  documented  procedure. 


T 

Documented  Procedure(s) 

References 

The  organization  develops  and  maintains  a  plan  for  software 
process  improvement  according  to  a  documented  procedure. 
(L5-37,  A3) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

Software  process  improvement  proposals  are  handled 
according  to  a  documented  procedure.  (L5-39,  A5) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 

When  the  decision  is  made  to  transfer  a  software  process 
improvement  into  normal  practice,  the  improvement  is 
implemented  according  to  a  documented  procedure.  (L5- 
42,  A8) 

[Refer  to  Level  5  Procedure  Checklists  for  additional 
information.] 
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PCM  Process  -  Training 


Training 


The  table  below  lists  the  training  recommended  for  the  process  change 
management  process. 


T 

Training 

References 

Software  managers  receive  required  training  in  software 
process  improvement.  (L5-34,  Ab2) 

The  managers  and  technical  staff  of  the  software 
engineering  group  and  other  software>reIated  groups 
receive  required  training  in  software  process  improvement. 
(L5-34,  Ab3) 

Senior  management  receives  required  training  in  software 
process  improvement.  (L5-35,  Ab4) 

Training  courses  are  updated  to  reflect  the  current  software 
process,  and  training  is  provided  before  installing  the 
process  change  for  general  use.  (L5-43,  A8,  3) 
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PCM  Process  -  Tools 


Tools 


The  table  below  lists  the  tools  recommended  for  the  process  change  management 
process. 


T 

Tools 

References 

Tools  to  support  process  improvement.  (L5'34,  Abl,  3) 
Examples  of  support  tools  include: 

□  statistical  analysis  tools, 

□  database  systems, 

□  process  automation  tods,  and 

□  process  modeling  tools. 

Support  tools  to  record  the  desired  data  (to  measure  and 
track  the  change  in  software  process  performance).  (L5-43, 
A8,  2.2) 
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Level  5  Procedure  Checklists 
Overview 


Introduction 


Purpose 


In  this  section 


This  section  describes  all  the  explicit  documented  procedures  in  the  Capability 
Maturity  Model  for  maturity  level  5. 


The  purpose  of  the  procedure  checklists  is  to  provide: 

•  Guidance  in  identifying  which  procedures  are  recommended  by  the  CMM  at 
level  5. 

•  Criteria  that  an  organization  can  use  to  evaluate  its  software  procedures  to 
determine  if  those  procedures  are  consistent  with  the  CMM  at  level  5. 

•  Information  that  can  be  used  to  develop  software  procedures  that  are  consistent 
with  the  CMM  at  level  5. 


This  section  covers  the  following  documented  procedures; 


CMM  Level  5  Procedures 

See  Page 

Defect  prevention  procedures 

L5-Procedures-2 

Technology  change  management  procedures 

L5-Procedures-3 

Process  change  management  procedures 

L5-Procedures>4 
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Defect  Prevention  (DP)  Procedures 


Documented 

procedure 


The  table  below  lists  the  recommended  documented  procedures  for  the  defect 
prevention  process. 


T 

Documented  Procedure 

References 

Causal  analysis  meetings  are  conducted  according  to  a 

documented  procedure.  (L5-7,  A3) 

This  procedure  typically  specifies  that: 

□  Each  team  that  performs  a  software  task  conducts 
causal  analysis  meetings. 

□  A  causal  analysis  meeting  is  conducted  shonly  after 
the  task  is  completed. 

□  Meetings  are  conducted  during  the  software  task  if 
and  when  the  number  of  defects  uncovered  warrants 
the  additional  meetings. 

□  Periodic  causal  analysis  meetings  are  conducted  after 
software  products  are  released  to  the  customer,  as 
appropriate. 

□  For  software  tasks  of  long  duration,  periodic  in- 
process  defect  prevention  meetings  are  conducted,  as 
appropriate. 

Q  The  meetings  are  led  by  a  person  trained  in  conducting 
causal  analysis  meetings. 

□  Defects  are  identified  and  analyzed  to  determine  their 
root  causes. 

□  The  defects  are  assigned  to  categories  of  root  causes. 

□  Proposed  actions  to  prevent  the  future  occurrence  of 
identified  defects  and  similar  defects  are  developed  and 
documented. 

□  Common  causes  of  defects  are  identified  and 
documented. 

□  The  results  of  the  meeting  are  recorded  for  use  by  the 
organization  and  other  projects. 

Revisions  to  the  organization’s  standard  software  process 
resulting  from  defect  prevention  actions  are  incorporated 
according  to  a  documented  procedure.  (LS-12,  A6) 

Revisions  to  the  project's  defined  software  process  resulting 
from  defect  prevention  actions  are  incorporated  according 
to  a  documented  procedure,  (L5-12,  A7) 
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Technology  Change  Management  (TCM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  technology 
change  management  process. 


T 

Documented  Procedures 

References 

Technologies  are  selected  and  acquired  for  the  organization 

and  software  projects  according  to  a  documented  procedure. 

(L5-26,  A5) 

This  procedure  typically  specifies  that: 

□  Requests  for  the  acquisition  of  new  technologies  are 
documented. 

□  Management  approval  is  required  for  technologies 
with  projected  expenses  above  a  predefined  level. 

□  Preliminary  cost/benefit  analyses  are  performed  for  the 
potential  technology  changes. 

□  Predefined  and  approved  selection  criteria  are  used  to 
identify  the  highest  potential  benefits. 

□  Requirements  and  plans  for  the  selected  technology 
changes  are  defined  and  documented. 

□  Where  practical,  the  expected  life  span  and  plans  for 
replacement/upgrade  ate  estimated. 

□  Where  appropriate,  tradeoff  studies  are  performed, 
reviewed,  and  documented  to  determine  whether  the 
technology  should  be  developed  internally  or 
procured  externally. 

□  Where  appropriate,  the  plan  provides  for  installing 
the  new  technology  on  a  pilot  basis  to  determine  its 
effectiveness  and  economic  benefits. 

□  The  requirements  and  plans  are  reviewed  by  the 
managers  of  the  affected  groups  and  the  group 
responsible  for  technology  change  management 
activities. 

Appropriate  new  technologies  are  incorporated  into  the 
organization's  standard  software  process  according  to  a 
documented  procedure.  (L5-28,  A7) 

Appropriate  new  technologies  are  incorporated  into  the 
projects’  defined  software  processes  according  to  a 
documented  procedure.  (L5-28,  A8) 
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Process  Change  Management  (PCM)  Procedures 


Documented 

procedures 


The  table  below  lists  the  recommended  documented  procedures  for  the  process 
change  management  process. 


T 

Documented  Procedures 

References 

The  organization  develops  and  maintains  a  plan  for  software 
process  improvement  according  to  a  documented  procedure. 
(L5-37.  A3) 

This  procedure  typically  specifies  that: 

□  The  software  process  improvement  plan  is  based  on: 

□  The  organization's  business  and  strategic  operating 
plans. 

□  Customer  satisfaction  indicators. 

□  The  software  process  improvement  plan  undergoes  peer 
review. 

□  The  software  process  improvement  plan  is  reviewed  by 
the  affected  managers. 

□  The  software  process  improvement  plan  is  managed  and 
controlled. 

Continued  on  next  page 
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Process  Change  Management  (PCM)  Procedures,  Continued 


Documented 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  process 
change  management  process  continued  from  the  previous  page. 


T 

Documented  Procedures 

References 

Software  process  improvement  proposals  are  handled 

according  to  a  documented  procedure.  (L5-39,  A5) 

This  procedure  typically  specifies  that: 

□  Software  process  improvement  proposals  are  submitted. 

□  Each  software  process  improvement  proposal  is 
evaluated;  a  decision  is  made  whether  to  implement  the 
proposal,  and  the  decision  rationale  is  documented. 

□  The  expected  benefits  of  each  software  process 
improvement  proposal  are  determined. 

□  The  priority  of  software  process  improvement  proposals 
selected  for  implementation  is  determined. 

□  Focus  on  high-priority  software  process 
improvement  proposals  is  maintained. 

□  Implementation  of  the  software  process  improvement 
actions  resulting  from  the  proposals  is  assigned  and 
planned. 

□  Software  process  improvement  actions  that  require  a 
substantial  effort  are  assigned  to  a  team  responsible  for 
implementation. 

□  The  status  of  each  software  process  improvement 
proposal  is  tracked. 

□  Software  process  improvement  proposals  for  which  the 
response  has  been  unusually  long  are  identified  and 
acted  upon. 

□  Software  process  changes  that  are  judged  to  have  a 
major  impact  on  product  quality  or  productivity  or  that 
will  significantly  alter  satisfaction  of  the  customer  and 
end  users  are  reviewed  and  approved  by  appropriate 
management  before  they  are  implemented. 

□  Completed  software  process  improvement  actions  are 
reviewed,  verified,  and  approved  before  they  are  closed. 

□  Submitters  of  the  software  process  improvement 
proposals  receive: 

□  Prompt  acknowledgment  of  their  proposals. 

□  Notification  of  the  disposition  of  their  proposals. 

Continued  on  next  page 
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Process  Change  Management  (PCM)  Procedures,  continued 


Documentod 

procedures, 

continued 


The  table  below  lists  the  recommended  documented  procedures  for  the  process 
change  management  process,  continued  from  the  previous  page. 


T 

Documented  Procedures 

References 

When  the  decision  is  made  to  transfer  a  software  process 
improvement  into  normal  practice,  the  improvement  is 
implemented  according  to  a  documented  procedure.  (LS- 
42.  A8) 

This  procedure  typically  specifies  that: 

□  The  resources  needed  to  support  major  changes  to  the 
software  process  are  established  and  ftmded. 

□  The  strategy  for  collecting  data  to  measure  and  track  the 
change  in  software  process  performance  is  documented, 
reviewed,  and  agreed  to. 

□  This  strategy  is  agreed  to  by  the  individuals 
responsible  for  implementing  the  software  processes 
affected  by  the  change. 

□  The  support  tools  are  instrumented,  as  appropriate, 
to  record  the  desired  data  automatically. 

□  Training  courses  are  updated  to  reflect  the  current 
software  process,  and  training  is  provided  before 
installing  the  process  change  for  general  use. 

□  Consultation  support,  appropriate  to  the  expected  needs, 
is  established  before  installing  the  process  change  for 
broad-scale  use  and  is  continued  as  needed. 

□  Appropriate  process  changes  are  incorporated  into  the 
organization's  standard  software  process. 

□  Appropriate  process  changes  are  incorporated  into  the 
projects'  defined  software  processes. 
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Level  5  Summary 
Overview 


Section  purpose  The  purpose  of  this  section  is  to  provide  checklists  that  provide  a  summary  of  the 

optimizing  level  (level  S).  lliis  section  contains  three  perspectives  of  a  CMM  level. 

•  Key  process  area  (KPA)  specific  information: 

KPA  purpose 

KPA  gojds 

•  Operational  framework  information  (from  a  maturity  level  viewpoint): 

Policies 

Standards 

Process  descriptions 

Procedures 

Training 

Tools 

•  Other  key  process  information  (from  a  maturity  level  viewpoint): 

Reviews  and  audits 

Work  products  managed  and  controlled 
Measurements 


Section  This  section  contains  the  following  topics, 

overview 


Topic 

Page 

Level  5  -  KPA  Purposes 

L5*Summary-2 

Level  5  -  KPA  Goals 

L5-Summary-3 

Level  5  -  Policies 

L5-Summary-4 

Level  5  -  Standards 

L5-Summary-5 

Level  5  -  Process  Descriptions 

L5-Summary-6 

Level  5  -  Procedures 

L5-Summary-8 

Level  5  -  Training 

L5-Summary-9 

Level  5  -  Tools 

L5-Summaiy-10 

Level  5  -  Reviews  and  Audits 

L5-Summary-1 1 

Level  S  -  Work  Products  Managed  and  Controlled 

L5-Summary-16 

Level  5  -  Measurements 

L5-Summary-17 

CMU/SEi^HB-1 


L5*Summary-1 


Level  5  -  KPA  Purposes 


Level  d'  KPA 
purposes 


The  following  table  describes  the  purpose  of  each  key  process  area  in  the  CMM  at 
level  5. 


T 

KPA 

Purpose  of  KPAs  at  Level  5 

DP 

The  purpose  of  Defect  Prevention  is  to  identify  the  cause  of  defects  and 
prevent  them  from  recurring.  (L5-1) 

TCM 

The  purpose  of  Technology  Change  Management  is  to  identify  new 
technologies  (i.e.,  tools,  methods,  and  processes)  and  track  them  into 
the  organization  in  an  orderly  manner.  G^-17) 

PCM 

The  purpose  of  Process  Change  Management  is  to  conUrually  improve 
the  software  processes  used  in  the  organization  with  the  intent  of 
improving  software  quality,  increasbig  productivity,  and  decreasing  the 
cycle  time  for  product  development  (L5-31) 
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Level  5  -  KPA  Goals 


Level  5  KPA 
goals 


The  following  table  lists  the  goals  that  are  described  in  the  CMM  at  level  5  for  each 
key  process  area. 


T 

KPA 

CMM  Goals  at  Level  S 

References 

DP 

Defect  prevention  activities  are  planned.  (L5-2,  Gl) 

DP 

Common  causes  of  defects  are  sought  out  and 
identified.  (L5-2,G2) 

DP 

Common  causes  of  defects  are  prioritized  and 
systematically  eliminated.  (L5-2,  G3) 

TCM 

Incorporation  of  technology  changes  are  planned.  (LS- 
18.  Gl) 

TCM 

New  technologies  are  evaluated  to  deteimine  their 
effect  on  quality  and  productivity.  (L5-18,  G2) 

TCM 

Appropriate  new  technologies  are  transferred  into 
normal  practice  across  the  organization.  (LS-18,  G3) 

PCM 

Continuous  process  improvement  is  planned.  (LS-32, 
Gl) 

PCM 

Participation  in  the  organization's  software  process 
improvement  activities  is  organization  wide.  (LS-32, 
G2) 

PCM 

The  organization's  standard  software  process  and  the 
projects'  defined  software  processes  are  improved 
continuously.  (L5-32,G3) 
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Level  5  -  Policies 


Level  5  policies  The  following  table  lists  the  tecommended  policies  in  the  CMM  at  level  5. 


References 


KPA 

Description 

DP 

Written  policy  for  defect  prevention  activities.  (L5-2, 
Cl) 

TCM 

Written  policy  for  improving  its  (the  organization’s) 
technology  capability.  (L5-18,C1) 

PCM 

Written  policy  for  implementing  software  process 
improvements.  (L5-32,  Cl) 
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Level  5  -  Standards 


Level  S 
standards 


Reference 


The  CMM  recommends  the  contents  of  the  following  work  products  at  level  5: 


T 

KPA 

Standards  at  Level  5 

References 

DP 

Project  plan  for  defect  prevention  activities.  (L5-5, 

Al) 

TCM 

Plan  for  technology  change  management  (L5-23,  Al) 

TCM 

Plan  for  pilot  eifoits  to  improve  technology.  (L5-27, 
A6) 

PCM 

Software  process  improvement  plan.  (L5-38,  A4) 

Refer  to  the  Level  5  Standards  Checklists  for  additional  information  regarding  the 
content  of  each  standard. 
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Level  5  -  Process  Descriptions 


DP  process 
description 


TCM  process 
description 


Defect  Prevention  involves  analyzing  defects  that  were  encountered  in  the  past  and 
taking  specific  actions  to  prevent  the  occurrence  of  those  types  of  defects  in  the  future. 
The  defects  may  have  been  identified  on  other  projects  as  well  as  in  earlier  stages  or 
tasks  of  the  current  project.  Defect  prevention  activities  are  also  one  mechanism  for 
spreading  lessons  learned  between  projects. 

Trends  are  analyzed  to  track  the  types  of  defects  that  have  been  encountered  and  to 
identify  defects  that  are  likely  to  recur.  Based  on  an  understanding  of  the  project's 
defined  software  process  and  how  it  is  implemented  (as  described  in  the  Integrated 
Software  Management  and  Software  Product  Engineering  key  process  areas),  the  root 
causes  of  the  defects  and  the  implications  of  the  defects  for  future  activities  are 
determined. 

Both  the  project  and  the  organization  take  specific  actions  to  prevent  recurrence  of  the 
defects.  Some  of  the  organizational  actions  may  be  handled  as  described  in  the 
Process  Change  Management  key  process  area.  (L5-1) 


Technology  Change  Management  involves  identifying,  selecting,  and  evaluating  new 
technologies,  and  incorporating  effective  technologies  into  the  organization.  The 
objective  is  to  improve  software  quality,  increase  productivity,  and  decrease  the  cycle 
time  for  product  development 

The  organization  establishes  a  group  (such  as  a  software  engineering  process  group  o: 
a  technology  suppon  group)  that  works  with  the  software  projects  to  introduce  and 
evaluate  new  technologies  and  manage  changes  to  existing  technologies.  Particular 
emphasis  is  placed  on  technology  changes  that  are  likely  to  improve  the  capability  of 
(he  organization's  standard  software  process  (as  described  in  the  Organization  Process 
Definition  key  process  area). 

By  maintaining  awareness  of  software-related  technology  innovations  and 
systematically  evaluating  and  experimenting  with  them,  the  organization  selects 
appropriate  technologies  to  improve  the  qu^ ity  of  its  software  and  the  productivity  of 
its  software  activities.  Pilot  efforts  ate  performed  to  assess  new  and  unproven 
technologies  before  they  are  incorporated  into  rwrmal  practice.  With  appropriate 
sponsorship  of  the  organization's  management,  the  selected  techiiologies  ate 
incorporated  into  the  organization's  standard  software  process  and  current  projects,  as 
appropriate. 

Qianges  to  the  organization's  standard  software  process  (as  described  in  the 
Organization  Process  Definition  key  process  area)  and  the  projects'  defined  software 
processes  (as  described  in  the  Integrated  Software  Management  key  process  area) 
resulting  from  these  technology  changes  ate  handled  as  described  in  the  Process 
Change  Management  key  process  area.  (L5-17) 


Continued  on  nex*  page 
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Level  5  -  Process  Descriptions,  Continued 


PCM  process  Process  Change  Management  involves  defining  process  improvement  goals  and,  with 
description  senior  management  sponsorship,  proactively  and  systematically  identifying, 

evaluating,  and  implementing  improvements  to  the  orgatuzation's  standard  software 
process  and  the  projects'  defined  software  processes  on  a  continuous  basis. 

Training  and  incentive  programs  are  established  to  enable  and  encourage  everyone  in 
the  organization  to  participate  in  process  improvement  activities.  Improvement 
opportunities  are  identified  and  evaluated  for  potential  payback  to  the  organization. 
Pilot  efforts  are  performed  to  assess  process  changes  before  they  are  incorporated  into 
normal  practice. 

When  software  process  improvements  are  approved  for  normal  practice,  the 
organization's  standard  software  process  and  the  projects'  defined  software  processes 
are  revised  as  appropriate.  The  practices  for  revising  the  organization's  standard 
software  process  are  found  in  the  Organization  Process  Definition  key  process  area, 
and  the  practices  for  revising  the  projects'  defined  software  processes  arc  found  in  the 
Integrated  Software  Management  key  process  area.  (L5-3 1) 
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Level  5  -  Procedures 


Reference 

Level  S 
procedures 


Refer  to  the  Level  5  Procedure  Checklists  for  additional  information  regarding  the 
content  of  each  documented  procedure. 


The  table  below  lists  the  activities  recommended  to  be  performed  according  to  a 
documented  procedure  in  the  CMM  at  level  5. 


T 

KPA 

Documented  Procedures 

References 

DP 

Causal  analysis  meetings  ate  conducted  according  to  a 
documented  procedure.  (L5-7,  A3) 

DP 

Revisions  to  the  organization's  standard  software 
process  resulting  ftom  defect  prevention  actions  are 
incorporated  according  to  a  documented  procedure. 
(L5-12.  A6) 

DP 

Revisions  to  the  project's  defined  software  process 
resulting  from  defect  prevention  actions  are 
incorporated  according  to  a  documented  procedure. 
(L5.12.A7) 

TCM 

Technologies  are  selected  and  acquired  for  the 
organization  and  software  projects  according  to  a 
documented  procedure.  (L5-26,A5) 

TCM 

Appropriate  new  technologies  are  incorporated  into  the 
organization's  standard  software  process  according  to  a 
documented  procedure.  tL5-28,  A7) 

TCM 

Appropriate  new  technologies  ate  incorporated  into  the 
projects'  defined  software  processes  according  to  a 
documented  procedure.  (L5-28,  A8) 

PCM 

The  organization  develops  and  maintains  a  plan  for 
software  process  improvement  according  to  a 
documented  procedure.  (L5-37,  A3) 

PCM 

Software  process  improvement  proposals  are  handled 
according  to  a  documented  procedure.  (L5-39,  A5) 

PCM 

When  the  decision  is  made  to  transfer  a  software 
process  improvement  into  normal  practice,  the 
improvement  is  implemented  according  to  a 
documented  procedure.  (L5-42,  A8) 
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Level  5  -  Training 


Level  5  training  The  table  below  lists  the  training  recommended  in  the  CMM  at  level  5. 


KPA 

Training 

DP 

Members  of  the  software  engineering  group  and 
other  software-related  groups  receive  required 
training  to  perform  their  defect  prevention  activities. 
(L5-4.  Ab4) 

TCM 

Members  of  the  group  responsible  for  the 
organization's  technology  change  management 
activities  receive  required  training  to  perform  these 
activities.  (L5-23,  Ab5) 

PCM 

Software  managers  receive  required  training  in 
software  process  improvement.  (L5-34,  Ab2) 

PCM 

The  managers  and  technical  staff  of  the  software 
engineering  group  and  other  software-related 
groups  receive  required  training  in  software  process 
improvement  (L5-34,  Ab3) 

PCM 

Senior  management  receives  required  training  in 
software  process  improvement.  ^5-35,  Ab4) 

PCM 

Training  courses  are  updated  to  reflect  the  current 
software  process,  and  training  is  provided  before 
installing  the  process  change  for  general  use.  (L5-43, 
A8, 3) 

References 
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Level  5  -  Tools 


Level  5  tools  The  table  below  lists  the  tools  recommended  in  the  CMM  for  level  5. 


T 

KPA 

Tools 

References 

DP 

Tools  to  support  defect  prevention  activities.  (L5-4, 
Ab3, 4) 

TCM 

Tools  to  support  technology  change  management.  (LS- 
21.  Ab2. 2) 

PCM 

Tools  to  support  process  improvemenL  (L5-34,  Abl, 

3) 

PCM 

Support  tools  to  record  the  desired  data  (to  measure 
and  track  the  change  in  software  process  performance). 
(L5-43,  A8,2.2) 
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Level  5  -  Reviews  and  Audits 


Level  5  reviews 
and  audits 


'Hie  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  5. 


T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

DP 

The  results  of  the  defect  prevention 
activities  are  reviewed  to  ensure  the 
effectiveness  of  those  activities. 
(L5-2.C1.4) 

Not  specified 
in  the  CMM 

DP 

The  software  project’s  plan  for 
defect  prevention  activities 
undergoes  peer  review.  (L5-5,  Al, 

4) 

Not  specifted 
in  the  CMM 

DP 

Each  of  the  teams  assigned  to 
coordinate  defect  prevention 
activities  meets  on  a  periodic  basis 
to  review  and  coordinate 
implementation  of  action  proposals 
from  the  causal  analysis  meetings. 
(L5-8,  A4) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

DP 

The  teams  assigned  to  coordinate 
defect  prevention  activities  review 
the  output  ftom  the  causal  analysis 
meetings  and  select  action  proposals 
that  will  be  addressed.  (LS-9,  A4, 1) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

DP 

The  teams  assigned  to  coordinate 
defect  prevention  activities  review 
action  proposals  that  have  been 
assign^  to  them  by  other  teams 
cooidinating  defect  prevention 
activities  in  the  organization  and 
select  action  proposals  that  will  be 
addressed.  (L5-9,A4,2) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

DP 

The  teams  assigned  to  coordinate 
defect  prevention  activities  review 
actions  taken  by  the  other  teams  in 
the  organization  to  assess  whether 
these  actions  can  be  applied  to  their 
activities  and  processes.  (L5-9,  A4, 

3) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

Continued  on  next  page 
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Level  5  *  Reviews  and  Audits,  continued 


Level  5  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  5, 
continued  from  the  previous  page. 


T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

DP 

The  teams  assigned  to  coordinate 
defect  prevention  activities  review 
results  of  defect  prevention 
experiments  and  take  actions  to 
incorporate  the  results  of  successful 
experiments  into  the  rest  of  the 
project  or  organization,  as 
appropriate.  (L5-10,  A4, 8) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

DP 

The  teams  assigned  to  coordinate 
defect  prevention  activities  review 
and  verify  completed  action  items 
before  they  are  closed.  (L5-10,  A4, 
11) 

Teams 

assigned  to 

coordinate 

defect 

prevention 

activities 

DP 

The  organization's  activities  for 
defect  prevention  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L5-14,V1) 

Senior 

maiuigement 

DP 

The  software  project’s  activities  for 
defect  prevention  are  reviewed  with 
the  project  manager  on  both  a 
periodic  and  event-driven  basis. 
(L5-15,V2) 

Project 

manager 

DP 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
defect  prevention  and  reports  the 
results.  (L5-15,V3) 

Software 

quality 

assurance 

group 

TCM 

Senior  management  helps  to 
establish  policies  for  teclmology 
change  management  and  reviews  and 
approves  these  policies.  (L5-19,  C3, 
1) 

Senior 

management 

TCM 

The  organizational  plan  for 
technology  change  management 
undergoes  peer  review.  $^-24,  Al, 
5) 

Not  specified 
in  CMM 

Continued  on  next  page 
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Level  5  -  Reviews  and  Audits,  continued 


Level  5  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  5, 
continued  from  the  previous  page. 


KPA 

Review  or  Audit 

Review 

Participants 

References 

TCM 

The  organizational  p*an  for 
technology  change  management  is 
reviewed  by  the  affected  managers. 
(L5-24,  Al,  6) 

Affected 

managers 

TCM 

The  group  responsible  for  the 
organization’s  technology  change 
management  activities  works  with 
the  software  projects  in  identifying 
areas  of  technology  changes. 

□  Systematic  efforts  are  made  to 
review  the  technologies  used 
externally  and  to  compare  these 
technologies  to  those  used 
within  the  organization.  (L5-25, 
A2, 2.3) 

Group 

responsible  for 
the 

organization’s 

technology 

change 

management 

activities 

TCM 

The  group  responsible  for  the 
organization’s  technology  change 
management  activities  works  with 
the  software  projects  in  identifying 
areas  of  technology  changes. 

□  Areas  where  new  technologies 
have  been  used  successfully  are 
identified,  and  data  and 
documentation  of  experience 
with  using  them  are  collected 
and  reviewed.  (L5-25,  A2, 2.4) 

Group 

responsible  for 
the 

organization’s 

te^nology 

change 

management 

activities 

TCM 

Where  appropriate,  tradeoff  studies 
are  performed,  reviewed,  and 
documented  to  determine  whether 
the  technology  should  be  developed 
internally  or  procured  externally. 
(L5-26,A5,4.2) 

Not  specified 
in  CMM 

TCM 

The  requirements  and  plans  (for 
selected  technology  changes)  are 
reviewed  by  the  managers  of  the 
affected  groups  and  the  group 
responsible  for  technology  change 
management  activities.  (L5'26, 

A5, 4.4) 

Managers  of 
the  affected 
groups 

Group 

responsible  for 

technology 

change 

management 

activities 

Continued  on  next  page 
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Level  5  -  Reviews  and  Audits,  continued 


Level  5  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  5, 
continued  from  the  previous  page. 


v 

KPA 

Review  or  Audit 

Review 

Participants 

References 

TCM 

The  plan  for  conducting  the  pilot 
effort  is  reviewed  and  approved  by 
the  managers  of  the  affected 
groups.  (L5-27,  A6, 3) 

Managers  of 
the  affected 
groups 

TCM 

The  organization’s  activities  for 
technology  change  management  are 
reviewed  with  senior  management 
on  a  periodic  basis.  (L5-29,  VI) 

Senior 

management 

TCM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  work  products  for 
technology  change  management  and 
reports  the  results.  (L5-29,  V2) 

Software 

quality 

assurance 

group 

PCM 

The  group  responsible  for  the 
organization’s  software  process 
activities  (e.g.,  software 
engineering  process  group)  reviev/s 
the  organizational  goals  for  process 
performance  with  senior 
management  for  their  endorsement. 
(L5-36,A2,2) 

Software 
engineering 
process  group 

Senior 

management 

PCM 

The  group  responsible  for  the 
organization's  software  process 
activities  (e.g.,  software 
engineering  process  group)  reviews 
software  process  improvement 
proposals  and  coordinates  the  actions 
for  these  proposals.  (L5-36,  A2, 5) 

Software 
engineering 
process  group 

PCM 

The  software  process  improvement 
plan  undergoes  peer  review.  (L5-37, 
A3, 2) 

Not  specified 
in  the  CMM 

PCM 

The  software  process  improvement 
plan  is  reviewed  by  the  affected 
managers.  (L5-37,  A3, 3) 

Affected 

managers 

Continued  on  next  page 
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Level  5  -  Reviews  and  Audits,  continued 


Level  5  reviews 
and  audits, 
continued 


The  table  below  lists  the  recommended  reviews  and  audits  in  the  CMM  at  level  5, 
continued  from  the  previous  page. 


T 

KPA 

Review  or  Audit 

Review 

Participants 

References 

PCM 

Software  process  changes  that  are 
judged  to  have  a  major  impact  on 
product  quality  or  productivity  or 
that  will  significantly  alter 
satisfaction  of  the  customer  and  end 
users  are  reviewed  and  approved  by 
appropriate  management  before 
they  are  implemented.  (L5-41,  A5, 

9) 

Management 

PCM 

Completed  software  process 
improvement  actions  are  reviewed, 
verified,  and  approved  before  they 
are  closed.  (L5-41,  A5, 10) 

Not  specified 
in  the  CMM 

PCM 

The  strategy  for  collecting  data  to 
measure  and  track  the  change  in 
software  process  performance  is 
documented,  reviewed,  and  agreed 
to.  (L5-43,A8.2) 

Not  specified 
in  the  CMM 

PCM 

The  activities  for  software  process 
improvement  are  reviewed  with 
senior  management  on  a  periodic 
basis.  (L5-46,  VI) 

Senior 

management 

PCM 

The  software  quality  assurance 
group  reviews  and/or  audits  the 
activities  and  woik  products  for 
software  process  improvement  and 
reports  the  results.  (L5-46,  V2) 

Software 

quality 

assurance 

group 
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Level  5  -  Work  Products  Managed  and  Controlled 


LeveJ  5  work  The  table  below  lists  the  work  products  that  are  recommended  to  be  managed  and 
products  controlled  in  the  CMM  at  level  5. 

managed  and 
controlled 


T 

KPA 

Work  Products  Managed  and  Controlled 

References 

DP 

Defect  prevention  data.  {L5-1 1 ,  A5, 3) 

TCM 

There  are  no  work  products  that  are  managed  and 
controlled  during  the  technology  change  management 
process. 

PCM 

Software  process  improvement  plan.  (L5-37,  A3, 4) 
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Level  5  -  Measurements 


Level  5 

measurements 


The  table  below  describes  the  recommended  measurements  in  the  CMM  at  level  5. 


T 

KPA 

Description 

References 

DP 

Defect  prevention  data.  (L5- 1 1 ,  A5) 

DP 

Measurements  to  determine  the  status  of  the  defect 
prevention  activities.  (L5-13,M1) 

TCM 

Data  of  experience  with  using  (new  technologies  that 
have  been  used  successfully).  (L5-25,  A2, 2.4) 

TCM 

Measurements  to  determine  the  status  of  the 
oiganization's  activities  for  technology  change 
management.  (LS-28,M1) 

PCM 

Measurements  to  determine  the  status  of  the  software 
process  improvement  activities.  (L5-4S,  Ml) 
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Appendices 

Overview 


Appendix 

contents 


The  appendices  and  their  descriptions  are  provided  in  the  table  below. 
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Appendix  A:  List  of  Acronyms 


List  of 
acronyms 


The  table  below  lists  the  acronyms  in  the  software  process  framework  and  their 
meaning. 


Acronym 

Meaning 

CMM 

Capability  maturity  model 

DP 

Defect  prevention 

IC 

Intergroup  coordination 

ISM 

Integrated  software  management 

KPA 

Key  process  area 

OPD 

Organization  process  definition 

OPF 

Organization  process  focus 

PAT 

Process  action  team 

PCM 

Process  change  management 

PR 

Peer  reviews 

QPM 

Quantitative  process  management 

RM 

Requirements  management 

SCM 

Software  configuration  management 

SEI 

Software  Engineering  Institute 

SEPG 

Software  engineering  process  group 

SPE 

Software  product  engineering 

SPF 

Software  process  framework 

SPP 

Software  project  planning 

SPTO 

Software  project  tracking  and  oversight 

SQA 

Software  quality  assurance 

SQM 

Software  quality  management 

SSM 

Software  subcontract  management 

TCM 

Technology  change  management 

TP 

Training  program 
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Appendix  B:  Glossary  of  Termsi 


A 

ability  to  perform 
acceptance  criteria 


acceptance  testing 


activity 


activities  performed 
action  item 

action  proposal 


agent* 

allocated  requirements 
application  domain 


assessment 

audit 

B 

baseline 


baseline  configuration 
management 


(See  common  features.) 

The  criteria  that  a  system  or  component  must  satisfy  in  order  to  be 
accepted  by  a  user,  customer,  or  other  authorized  entity,  [lEEE- 
STD-610] 

Formal  testing  conducted  to  determine  whether  or  not  a  system 
satisfies  its  acceptance  criteria  and  to  enable  the  customer  to 
determine  whether  or  not  to  accept  the  system.  flEEE-STD-blO] 

Any  step  taken  or  function  performed,  both  mental  and  physical, 
toward  achieving  some  objective.  Activities  include  all  the  work  the 
managers  and  technical  staff  do  to  perform  the  tasks  of  the  project 
and  organization.  (See  task  for  contrast.) 

(See  common  features.) 

(1)  A  unit  in  a  list  that  has  been  assigned  to  an  individual  or  group 
for  disposition.  (2)  An  action  proposal  that  has  been  accepted. 

A  documented  suggestion  for  change  to  a  process  or  process-related 
item  that  will  prevent  the  future  occurrence  of  defects  identified  as  a 
result  of  defect  prevention  activities.  (See  also  software  process 
improvement  proposal.) 

(See  role.) 

(See  system  requirements  allocated  to  software.) 

A  bounded  set  of  related  systems  (i.e.,  systems  that  address  a 
particular  type  of  problem).  Development  and  maintenance  in  an 
application  domain  usually  requires  special  skills  and/or  resources. 
Examples  include  payroll  and  personnel  systems,  command  and 
control  systems,  compilers,  and  expert  systems. 

(See  software  process  assessment.) 

An  independent  examination  of  a  work  product  or  set  of  work 
products  to  assess  compliance  with  specifications,  standards, 
contractual  agreements,  or  other  criteria.  [IEEE-STD-610] 


A  specification  or  product  that  has  been  formally  reviewed  and 
agreed  upon,  that  thereafter  serves  as  the  basis  for  further 
development,  and  that  can  be  changed  only  through  formal  change 
control  procedures.  [IEEE-STD-610] 

The  establishment  of  baselines  that  are  formally  reviewed  and 
agreed  on  and  serve  as  the  basis  for  further  development.  Some 
software  work  products,  e.g.,  the  software  design  and  the  code, 
should  have  baselines  established  at  predetermined  points,  and  a 
rigorous  ch^ge  control  process  should  be  applied  to  these  items. 
These  baselines  provide  control  and  stability  when  interacting  with 
the  customer.  (See  also  baseline  management.) 


*  Unless  denoted  by  an  asterisk,  all  terms  are  as  defined  in  [Paulk93b]. 
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baseline  management 

benchmark 

bidder 

c 

capability  maturity  model 

causal  analysis 
causal  analysis  meeting 

commitment 

commitment  to  perform 
common  cause  (of  a  defect) 

common  features 


In  configuration  management,  the  application  of  technical  and 
administrative  direction  to  designate  the  documents  and  changes  to 
those  documents  that  formally  identify  and  establish  baselines  at 
specific  times  during  the  life  cycle  of  a  configuration  item.  [lEEE- 
STD-610] 

A  standard  against  which  measurements  or  comparisons  can  be 
made.  [IEEE-STD-610] 

An  individual,  partnership,  corporation,  or  association  that  has 
submitted  a  proposal  and  is  a  candidate  to  be  awarded  a  contract  to 
design,  develop,  and/or  manufacture  one  or  more  products. 


A  description  of  the  stages  through  which  software  organizations 
evolve  as  they  define,  implement,  measure,  control,  and  improve 
their  software  processes.  This  model  provides  a  guide  foi  selecting 
process  improvement  strategies  by  facilitating  the  determination  of 
current  process  capabilities  and  the  identification  of  the  issues  most 
critical  to  software  quality  and  process  improvement. 

The  analysis  of  defects  to  determine  their  underlying  root  cause. 

A  meeting,  conducted  after  completing  a  specific  task,  to  analyze 
defects  uncovered  during  the  performance  of  that  task. 

A  pact  that  is  freely  assumed,  visible,  and  expected  to  be  kept  by  all 
parties. 

(See  common  features.) 

A  cause  of  a  defect  that  is  inherently  part  of  a  process  or  system. 
Common  causes  affect  every  outcome  of  the  process  and  everyone 
working  in  the  process.  (See  special  cause  for  contrast.) 

The  subdivision  categories  of  the  CMM  key  process  areas.  The 
common  features  are  attributes  that  indicate  whether  the 
implementation  and  institutionalization  of  a  key  process  area  is 
effective,  repeatable,  and  lasting.  The  CMM  common  features  are 
the  following: 

□  commitment  to  perform:  The  actions  the  organization  must 
ta!:e  to  ensure  that  the  process  is  established  and  will  endure. 
Commitment  to  Perform  typically  involves  establishing 
organizational  policies  and  senior  management  sponsorship. 

□  ability  to  perform:  The  preconditions  that  must  exist  in  the 
project  or  organization  to  implement  the  software  process 
competently.  Ability  to  Perform  typically  involves  resources, 
organizational  structures,  and  training. 

□  activities  performed:  A  description  of  the  roles  and  procedures 
necessary  to  implement  a  key  process  area.  Activities 
Performed  typically  involve  establishing  plans  and  procedures, 
performing  the  work,  tracking  it,  and  uddng  corrective  actions 
as  necessary. 

Definition  continued  on  next  page 
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common  features,  continued 


configuration 
configuration  control 


confi(it,ration  identification 


configuration  item 
configuration  management 


configuration  management 
library  system 

configuration  unit 

consistency 

contingency  factor 

contract  terms  and  conditions 
critical  computer  resource 

critical  path 
customer 


□  measurement  and  analysis :  A  description  of  the  need  to 
measure  the  process  and  analyze  the  measurements. 
Measurement  and  Analysis  typically  includes  examples  of  the 
measurements  that  could  be  t^en  to  determine  the  status  and 
effectiveness  of  the  Activities  Performed. 

□  verifying  implementation:  The  steps  to  ensure  that  the 
activities  are  performed  in  compliance  with  the  process  that  has 
been  established.  Verification  typically  encompasses  reviews 
and  audits  by  management  and  software  quality  assurance. 

In  configuration  management,  the  functional  and  physical 
characteristics  of  hardware  or  software  as  set  forth  in  technical 
documentation  or  achieved  in  a  product.  {IEEE-STD-610] 

An  element  of  configuration  management,  consisting  of  the 
evaluation,  coordination,  approval  or  disapproval,  and 
implementation  of  changes  to  configuration  items  after  formal 
establishment  of  their  configuration  identification.  [IEEE-STD- 
610] 

An  element  of  configuration  management,  consisting  of  selecting 
the  configuration  items  for  a  system  and  recording  their  functional 
and  physical  characteristics  in  technical  documentation.  [IEEE- 
STD-610] 

An  aggregation  of  hardware,  software,  or  both,  that  is  designated  for 
configuration  management  and  treated  as  a  single  entity  in  the 
configuration  management  process.  [IEEE-STD-610] 

A  discipline  applying  technical  and  administrative  direction  and 
surveillance  to  identify  and  document  the  functional  and  physical 
characteristics  of  a  configuration  item,  control  changes  to  those 
characteristics,  record  and  report  change  processing  and 
implementation  status,  and  verify  compliance  with  specified 
requirements.  [IEEE-STD-610] 

The  tools  and  procedures  to  access  the  contents  of  the  software 
baseline  library. 

The  lowest  level  entity  of  a  configuration  item  or  component  that 
can  be  placed  into,  and  retrieved  from,  a  configuration  management 
library  system. 

The  degr^  of  uniformity,  standardization,  and  freedom  from 
contradiction  among  the  documents  or  parts  of  system  or 
component.  [IEEE-STD-610] 

An  adjustment  (increase)  of  a  size,  cost,  or  schedule  plan  to  account 
for  likely  underestimates  of  these  parameters  due  to  incomplete 
specification,  inexperience  in  estimating  the  application  domain,  etc. 

The  stated  legal,  financial,  and  administrative  aspects  of  a  contract. 

The  parameters  of  the  computing  resources  deemed  to  be  a  source 
of  risk  to  the  project  because  the  potential  need  for  those  resources 
may  exceed  the  amount  that  is  available.  Examples  include  target 
computer  memory  and  host  computer  disk  space. 

A  series  of  dependent  tasks  for  a  project  that  must  be  completed  as 
planned  to  keep  the  entire  project  on  schedule. 

The  individual  or  organization  that  is  responsible  for  accepting  the 
product  and  authorizing  payment  to  the  developing  organization. 
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D 

defect 

defect  density 

defect  prevention 

defect  root  cause 

defined  level 
defined  software  process 
dependency  item 

developmental  configuration 
management 


deviation 

documented  procedure 

E 

effective  process 
end  user 

end  user  representatives 
engineering  group 

entry  criteria* 
exit  criteria* 
evaluation 


A  flaw  in  a  system  or  system  component  that  causes  the  system  or 
component  to  fail  to  perform  its  required  function.  A  defect,  if 
encountered  during  execution,  may  cause  a  failure  of  the  system. 

The  number  of  defects  identified  in  a  product  divided  by  the  size  of 
the  product  component  (expressed  in  standard  measurement  terms 
for  that  product). 

The  activities  involved  in  identifying  defects  or  potential  defects  and 
preventing  them  from  being  introduced  into  a  product. 

The  underlying  reason  (e.g.,  process  deficiency)  that  allowed  a 
defect  to  be  introduced. 

(See  maturity  level.) 

(See  project's  defined  software  process.) 

A  product,  action,  piece  of  information,  etc.,  that  must  be  provided 
by  one  individual  or  group  to  a  second  individual  or  group  so  that 
the  second  individual  or  group  can  perform  a  planned  task. 

The  application  of  technical  and  administrative  direction  to 
designate  and  control  software  and  associated  technical 
documentation  that  define  the  evolving  configuration  of  a  software 
work  product  during  development.  Developmental  configuration 
management  is  under  the  direct  control  of  the  developer.  Items 
under  developmental  configuration  management  are  not  baselines, 
although  they  may  be  baselined  and  placed  under  baseline 
configuration  management  at  some  point  in  their  development. 

A  noticeable  or  marked  departure  from  the  appropriate  norm,  plan, 
standard,  procedure,  or  variable  being  reviewed. 

(See  procedure.) 


A  process  that  can  be  characterized  as  practiced,  documented, 
enforced,  trained,  measured,  and  able  to  improve.  (See  also  well- 
defined  process.) 

The  individual  or  group  who  will  use  the  system  for  its  intended 
operational  use  when  it  is  deployed  in  its  environment. 

A  selected  sample  of  end  users  who  represent  the  total  population  of 
end  users. 

A  collection  of  individuals  (both  managers  and  technical  stafO 
representing  an  engineering  discipline.  Examples  of  engineering 
disciplines  include  systems  engineering,  hardware  engineering, 
system  test,  software  engineering,  software  configuration 
management,  and  software  quality  assurance. 

The  conditions  under  which  an  activity  can  be  started.  Entry  criteria 
often  take  the  form  of  a  simple  or  compound  predicate  about  the 
state  of  a  work  product,  role,  or  activity. 

The  conditions  under  which  an  activity  can  be  declared  complete. 
Exit  criteria  often  take  the  form  of  a  simple  or  compound  predicate 
about  the  state  of  an  artifact,  role,  or  activity. 

(See  software  capability  evaluation.) 
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event-driven  review/activity 

F 

findings 

first-line  software  manager 

formal  review 

function 

G 

goals 

group 

H 

host  computer 

1 

initial  level 
input* 

institutionalization 

integrated  software 
management 

integration 


A  review  or  activity  that  is  performed  based  on  the  occurrence  of  an 
event  within  the  project  (e.g.,  a  formal  review  or  the  completion  of  a 
life  cycle  stage).  (See  periodic  review/activity  for  contrast.) 


The  conclusions  of  an  assessment,  evaluation,  audit,  or  review  that 
identify  the  most  important  issues,  problems,  or  opportunities  within 
the  area  of  investigation. 

A  manager  who  has  direct  management  responsibility  (including 
providing  technical  direction  and  administering  the  personnel  and 
salary  functions)  for  the  staffing  and  activities  of  a  single 
organizational  unit  (e.g.,  a  department  or  project  team)  of  software 
engineers  and  other  related  staff. 

A  formal  meeting  at  which  a  product  is  presented  to  the  end  user, 
customer,  or  other  interested  parties  for  comment  and  approval.  It 
can  also  be  a  review  of  the  management  and  technical  activities  and 
of  the  progress  of  the  project. 

A  set  of  related  actions,  undertaken  by  individuals  or  tools  that  are 
specifically  assigned  or  fitted  for  their  roles,  to  accomplish  a  set 
purpose  or  end. 


A  summary  of  the  key  practices  of  a  key  process  area  that  can  be 
used  to  determine  whether  an  organization  or  project  has  effectively 
implemented  the  key  process  area.  The  goals  signify  the  scope, 
boundaries,  and  intent  of  each  key  process  area. 

The  collection  of  departments,  managers,  and  individuals  who  have 
responsibility  for  a  set  of  tasks  or  activities.  A  group  could  vary 
from  a  single  individual  assigned  part  time,  to  sever^  part-time 
individuals  assigned  from  different  departments,  to  several 
individuals  dedicated  full  time. 


A  computer  used  to  develop  software.  (See  target  computer  for 
contrast.) 


(See  maturity  level.) 

The  relationship  or  link  between  an  activity  and  a  work  product. 
Inputs  are  the  results  produced  by  a  prior  activity  and  used  by  the 
current  activity  and  may  be  qualified  by  the  state  of  a  woric  product. 

The  building  of  infrastructure  and  corporate  culture  that  support 
methods,  practices,  and  procedures  so  that  they  are  the  ongoing  way 
of  doing  business,  even  after  those  who  originally  defined  them  are 
gone. 

The  unification  and  integration  of  the  software  engineering  and 
management  activities  into  a  coherent  defined  .software  process 
based  on  the  organization's  standard  software  process  and  related 
process  assets. 

(See  software  integration.) 
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K 

key  practices 
key  process  area 


L 

life  cycle 

M 

maintenance 
managed  and  contrr  ued 


managed  level 
manager 


maturity  level 


The  infrastructures  and  activities  that  contribute  most  to  the  effective 
implementation  and  institutionalization  of  a  key  process  area. 

A  cluster  of  related  activities  that,  when  performed  collectively, 
achieve  a  set  of  goals  considered  important  for  establishing  process 
capability.  The  key  process  areas  have  been  defined  to  reside  at  a 
single  maturity  level.  They  are  the  areas  identified  by  the  SEI  to  be 
the  principal  building  blocks  to  help  determine  the  software  process 
capability  of  an  organization  and  understand  the  improvements 
needed  to  advance  to  higher  maturity  levels.  The  level  2  key 
process  areas  in  the  CMM  are  Requirements  Management,  Software 
Project  Planning,  Software  Project  Tracking  and  Oversight,  Software 
Subcontract  Management,  Software  Quality  Assurance,  and  Software 
Configuitition  Management.  The  level  3  key  process  areas  in  the 
CMM  are  Organization  Process  Focus,  Organization  Process 
Definition,  Ti  -inijig  Program,  Integrated  Software  Management, 
Software  Prodiici  Engineering,  Intergroup  Coordination,  and  Peer 
Reviews.  ^  ne  level  4  key  _  jcess  areas  are  Quantitative  Process 
Management  Sor'ware  Quality  Management.  The  level  5  key 
process  areaj  m  r-ei-.  '•  Prevention,  Technology  Change 
Management,  and  T.ocess  Change  Management. 


(See  sofr‘ .  'ft  ufs  cycle.) 


The  prcc‘*..'s  z':  modifying  a  software  system  or  component  after 
delivery  y/v.:.:  faulU,  improve  performance  or  other  attributes, 
or  adap.  ‘o  a  '  h  -  «;»- j  environment.  [IEEE-STD-610] 

The  process  ot  ic  -ntifying  and  defining  software  work  products  that 
are  not  part  oi  a  b  iseline  and,  therefore,  are  not  placed  under 
configuration  management  but  that  must  be  controlled  for  the 
project  to  proceed  in  a  disciplined  manner.  "Managed  and 
controlled"  implies  that  the  version  of  the  work  product  in  use  at  a 
given  time  (past  or  present)  is  known  (i.e.,  version  control),  and 
changes  are  incorporated  in  a  controlled  manner  (i.e.,  change 
control). 

(See  maturity  level.) 

A  rotw  that  encompasses  providing  technical  and  administrative 
direction  and  control  to  individuals  performing  tasks  or  activities 
within  the  manager's  area  of  responsibility.  The  traditional 
functions  of  a  manager  include  planning,  resourcing,  organizing, 
directing,  and  controlling  work  within  an  area  of  responsibility. 

A  well-defined  evolutionary  plateau  toward  achieving  a  mature 
software  process.  The  five  maturity  levels  in  the  SEI's  Capability 
Maturity  Model  are: 

□  initial:  The  software  process  is  characterized  as  ad  hoc,  and 
occasionally  even  chaotic.  Few  processes  are  defined,  and 
success  depends  on  individual  effort. 

Definition  continued  on  next  page 
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maturity  level,  continued 


□  repeatable:  Basic  project  management  processes  are  established 
to  track  cost,  schedule,  and  functionality.  The  necessary  process 
discipline  is  in  place  to  repeat  earlier  successes  on  projects  with 
similar  applications. 

□  defined:  The  software  process  for  both  management  and 
engineering  activities  is  documented,  standardized,  and 
integrated  into  a  standard  software  process  for  the  organization. 
All  projects  use  an  approved,  tailored  version  of  the 
organization's  standard  software  process  for  developing  and 
maintaining  software. 

□  managed:  Detailed  measures  of  the  software  process  and 
product  quality  ate  collected.  Both  the  software  process  and 
products  are  quantitatively  understood  and  controlled. 

□  optimizing:  Continuous  process  improvement  is  enabled  by 
quantitative  feedback  from  the  process  and  from  piloting 
innovative  ideas  and  technologies. 

maturity  questionnaire  A  set  of  questions  about  the  software  process  that  sample  the  key 


measure 

measurement 

method 


methodology 


milestone 

N 

nontechnical  requirements  Agreements,  conditions,  and/or  contractual  terms  that  affect  and 

determine  the  management  activities  of  a  software  project. 


practices  in  each  key  process  area  of  the  CMM.  The  maturity 
questionnaire  is  used  as  a  springboard  to  appraise  the  capability  of 
an  organization  or  project  to  execute  a  software  process  reliably. 

A  unit  of  measurement  (such  as  source  lines  of  code  or  document 
pages  of  design). 

The  dimension,  capacity,  quantity,  or  amount  of  something  (e.g., 

300  source  lines  of  code  or  7  document  pages  of  design). 

A  reasonably  complete  set  of  rules  and  criteria  that  establish  a 
precise  and  repeatable  way  of  performing  a  task  and  arriving  at  a 
desired  result. 

A  collection  of  methods,  procedures,  and  standards  that  defines  an 
integrated  synthesis  of  engineering  approaches  to  the  development 
of  a  product. 

A  scheduled  event  for  which  some  individual  is  accountable  and  that 
is  used  to  measure  progress. 


o 

operational  software  The  software  that  is  intended  to  be  used  and  operated  in  a  system 

when  it  is  delivered  to  its  customer  and  deployed  in  its  intended 
environment. 

optimizing  level  (See  maturity  level.) 

organization  A  unit  within  a  company  or  other  entity  (e.g.,  government  agency  or 

branch  of  service)  within  which  many  projects  are  managed  as  a 
whole.  All  projects  within  an  organization  share  a  common  top- 
level  manager  and  common  policies. 

organization's  measurement  The  set  of  related  elements  for  addressing  an  organization's 

program  measurement  needs.  It  includes  the  definition  of  organization-wide 

measurements,  methods  and  practices  for  collecting  organizational 
measurement  data,  methods  and  practices  for  analyzing 
organizational  measurement  data,  and  measurement  goals  for  the 
organization. 
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organization's  software 
process  assets 


organization's  software 
process  database 


organization's  standard 
software  process 

orientation 

output* 

P 

Pareto  analysis 

peer  review 
peer  review  leader 


A  collection  of  entities,  maintained  by  an  organization,  for  use  by 
projects  in  developing,  tailoring,  maintaining,  and  implementing 
their  software  processes.  These  software  process  assets  typically 
include; 

□  the  organization's  standard  software  process, 

□  descriptions  of  the  software  life  cycles  approved  for  use, 

□  the  guidelines  and  criteria  for  tailoring  the  organization's 
standard  software  process, 

□  the  organization's  software  process  database,  and 

□  a  library  of  software  process-related  documentation. 

Any  entity  that  the  organization  considers  useful  in  performing  the 
activities  of  process  definition  and  maintenance  could  be  included  as 
a  process  asset. 

A  database  established  to  collect  and  make  available  data  on  the 
software  processes  and  resulting  software  work  products, 
particularly  as  they  relate  to  the  organization's  standard  software 
process.  TTie  database  contains  or  references  both  the  actual 
measurement  data  and  the  related  information  needed  to  understand 
the  measurement  data  and  assess  it  for  reasonableness  and 
applicability.  Examples  of  process  and  work  product  data  include 
estimates  of  software  size,  effort,  and  cost;  actual  data  on  software 
size,  effort,  and  cost;  productivity  data;  peer  review  coverage  and 
efficiency;  and  numl^r  and  severity  of  defects  found  in  the 
software  code. 

The  operational  definition  of  the  basic  process  that  guide's  the 
establishment  of  a  common  software  process  across  the  software 
projects  in  an  organization.  It  describes  the  fundamental  software 
process  elements  that  each  software  project  is  expected  to 
inco^orate  into  its  defined  software  process.  It  also  describes  the 
relationships  (e.g.,  ordering  and  interfaces)  between  these  software 
process  elements. 

An  overview  or  introduction  to  a  topic  for  those  overseeing  or 
interfacing  with  the  individuals  responsible  for  p  ^forming  in  the 
topic  area.  (See  train  for  contrast.) 

The  relationship  or  link  between  an  activity  and  a  work  product. 
Outputs  are  the  results  produced  by  the  current  activity  and  used  by 
a  subsequent  activity  and  may  be  qualified  by  the  state  of  a  work 
product. 


The  analysis  of  defects  by  ranking  causes  from  most  significant  to 
least  significant.  Pareto  analysis  is  based  on  the  principle,  named 
after  the  19th-century  economist  Vilfredo  Pareto,  that  most  effects 
come  from  relatively  few  causes,  i.e.,  80%  of  the  effects  come  from 
20%  of  the  possible  causes. 

A  review  of  a  software  work  product,  following  defined  procedures, 
by  peers  of  the  producers  of  the  product  for  the  purpose  of 
identifying  defects  and  improvements. 

An  individual  specifically  trained  and  qualified  to  plan,  organize, 
and  lead  a  peer  review. 
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periodic  review/activity 
policy 

prime  contractor 

procedure 

process 

process  capability 
process  capability  baseline 

process  database 
process  description 

process  development 
process  measurement 

process  performance 
process  performance  baseline 

process  tailoring 

product 

profile 

project 


A  review  or  activity  that  occurs  at  specified  regular  time  intervals. 

(See  evenudriven  review/activity  for  contrast.) 

A  guiding  principle,  typically  established  by  senior  management, 
which  is  adopted  by  an  organization  or  project  to  influence  and 
determine  decisions. 

An  individual,  partnership,  corporation,  or  association  that 
administers  a  subcontract  to  design,  develop,  and/or  manufacture 
one  or  more  products. 

A  written  description  of  a  course  of  action  to  be  taken  to  perform  a 
given  task.  [IEEE-STD-610] 

A  sequence  of  steps  performed  for  a  given  purpose;  for  example, 
the  software  development  process.  [DEEE-STD-610] 

The  range  of  expected  results  that  can  be  achieved  by  following  a 
process.  (See  process  performance  for  contrast.) 

A  documented  characterization  of  the  range  of  expected  results  that 
would  normally  be  achieved  by  following  a  specific  process  under 
typical  circumstances.  A  process  capability  baseline  is  typically 
established  at  an  organizational  level.  (See  process  performance 
baseline  for  contrast.) 

(See  organization’s  software  process  database.) 

The  operational  definition  of  the  major  components  of  a  process. 
Documentation  that  specifies,  in  a  complete,  precise,  verifiable 
manner,  the  requirements,  design,  behavior,  or  other  characteristics 
of  a  process.  It  may  also  include  the  procedures  for  determining 
whether  these  provisions  have  been  satisfied.  Process  descriptions 
may  be  found  at  the  task,  project,  or  organizational  level. 

The  act  of  defining  and  describing  a  process.  It  may  include 
planning,  architecture,  design,  implementation,  and  validation. 

The  set  of  definitions,  methods,  and  activities  used  to  take 
measurements  of  a  process  and  its  resulting  products  for  the  purpose 
of  characterizing  and  understanding  the  process. 

A  measure  of  the  actual  results  achieved  by  following  a  process. 

(See  process  capability  for  contrast.) 

A  documented  characterization  of  the  actual  results  achieved  by 
following  a  process,  which  is  used  as  a  benchmark  for  comparing 
actual  process  performance  against  expected  process  performance. 

A  process  performance  baseline  is  typically  established  at  the  project 
level,  although  the  initial  process  performance  baseline  will  usually 
be  derived  from  the  process  capability  baseline.  (See  process 
capability  baseline  for  contrast.) 

The  activity  of  creating  a  process  description  by  elaborating, 
adapting,  and/or  completing  the  details  of  process  elements  or  other 
incomplete  specifications  of  a  process.  Specific  business  needs  for  a 
project  will  usually  be  addressed  during  process  tailoring. 

(See  software  product  and  software  work  product.) 

A  comparison,  usually  in  graphical  form,  of  plans  or  projections 
versus  actuals,  typically  over  time. 

An  undertaking  requiring  concerted  effort,  which  is  focused  on 
developing  an^or  maintaining  a  specific  product.  The  product  may 
include  hardware,  software,  and  other  components.  Typically  a 
project  has  its  own  funding,  cost  accounting,  and  delivery  schedule. 
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project's  defined  software 
process 


project  manager 

project  software  manager 

Q 

quality 

quality  assurance 
quantitative  control 

R 

repeatable  level 
required  training 

risk 

risk  management 

risk  management  plan 
role 

s 

senior  manager 

software  architecture 


The  operational  definition  of  the  software  process  used  by  a  project. 
The  project's  defined  software  process  is  a  well-characterized  and 
understood  software  process,  described  in  terms  of  software 
standards,  procedures,  tools,  and  methods.  It  is  developed  by 
tailoring  the  organization's  standard  software  process  to  fit  the 
specific  characteristics  of  the  project.  (See  also  organization's 
standard  software  process,  effective  process,  and  well-defined 
process.) 

The  role  with  total  business  responsibility  for  an  entire  project;  the 
individual  who  directs,  controls,  administers,  and  reguiates  a  project 
building  a  software  or  hardware/software  system.  'Die  project 
manager  is  the  individual  ultimately  responsible  to  the  customer. 

The  role  with  total  responsibility  for  all  the  software  activities  for  a 
project.  The  project  software  manager  is  the  individual  the  project 
manager  deals  with  in  terms  of  software  commitments  and  who 
controls  all  the  software  resources  for  a  project. 


(1)  The  degree  to  which  a  system,  component,  or  process  meets 
specified  requirements.  (2)  The  degree  to  which  a  system. 

Cl",  .  o.  ''-ocess  meets  customer  or  user  needs  or 
.^  iciatiops.  f’’2EE-STD-610] 

\ software  quality  assurance.) 

.  ..\y  quantitative  or  statistically-based  technique  appropriate  to 
analyze  a  software  process,  identify  special  causes  of  variations  in 
the  performance  of  the  software  process,  and  bring  the  performance 
of  the  software  process  within  well-defined  limits. 


(See  maturity  level.) 

Training  designated  by  an  organization  to  be  required  to  perform  a 
specific  role. 

Possibility  of  suffering  loss. 

An  approach  to  problem  analysis  which  weighs  risk  in  a  situation  by 
using  risk  probabilities  to  give  a  more  accurate  understanding  of  the 
risks  involved.  Risk  management  includes  risk  identification, 
analysis,  prioritization,  and  control. 

The  collection  of  plans  that  describe  the  risk  management  activities 
to  be  performed  on  a  project. 

A  unit  of  defined  responsibilities  that  may  be  assumed  by  one  or 
more  individuals. 


A  management  role  at  a  high  enough  level  in  an  organization  that 
the  primary  focus  is  the  long-term  vitality  of  the  organization,  rather 
than  short-term  project  and  contractual  concerns  and  pressures.  In 
general,  a  senior  manager  for  engineering  would  have  responsibility 
for  multiple  projects. 

The  organizational  structure  of  the  software  or  module.  [lEEE- 
STD-610] 
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software  baseline  audit 


software  baseline  library 
software  build 

software  capability  evaluation 

software  configuration  control 
board 

software  development  plan 

software  engineering  group 

software  engineering  process 
group 

software  engineering  staff 

software  integration 
software  life  cycle 

software  manager 
software  plans 


An  examination  of  the  structure,  contents,  and  facilities  of  the 
software  baseline  library  to  verify  that  baselines  conform  to  the 
documentation  that  describes  the  baselines. 

The  contents  of  a  repository  for  storing  configuration  items  and  the 
associated  records. 

An  operational  version  of  a  software  system  or  component  that 
incorporates  a  specified  subset  of  the  capabilities  the  final  software 
system  or  component  will  provide.  [IEEE-STD-610] 

An  appraisal  by  a  trained  team  of  professionals  to  identify 
contractors  who  are  qualified  to  perform  the  software  work  or  to 
monitor  the  state  of  the  software  process  used  on  an  existing 
software  effort. 

A  group  responsible  for  evaluating  and  approving  or  disapproving 
proposed  changes  to  configuration  items,  and  for  ensuring 
implementation  of  approved  changes. 

The  collection  of  plans  that  describe  the  activities  to  be  performed 
for  the  software  project.  It  governs  the  management  of  the  activities 
performed  by  the  software  engineering  group  for  a  software  project. 
It  is  not  limited  to  the  scope  of  any  particular  planning  standard, 
such  as  DOD-STD-2167A  and  IEEE-STD-1058,  which  may  use 
similar  terminology. 

The  collection  of  individuals  (both  managers  and  technical  staff) 
who  have  responsibility  for  software  development  and  maintenance 
activities  (i.e.,  requirements  analysis,  design,  code,  and  test)  for  a 
project.  Groups  performing  software-related  work,  such  as  the 
software  quality  assurance  group,  the  software  configuration 
management  group,  and  the  software  engineering  process  group,  are 
not  included  in  the  software  engineering  group. 

A  group  of  specialists  who  facilitate  the  definition,  maintenance,  and 
improvement  of  the  software  process  used  by  the  organization.  In 
the  key  practices,  this  group  is  generically  referred  to  as  "the  group 
responsible  for  the  organization’s  software  process  activities." 

The  software  technical  people  (e.g.,  analysts,  programmers,  and 
engineers),  including  software  task  leaders,  who  perform  the 
software  development  and  maintenance  activities  for  the  project,  but 
who  are  not  managers. 

A  process  of  putting  together  selected  software  components  to 
provide  the  set  or  specified  subset  of  the  capabilities  the  final 
software  system  will  provide. 

The  period  of  time  that  begins  when  a  software  product  is  conceived 
and  ends  when  the  software  is  no  longer  available  for  use.  The 
software  life  cycle  typically  includes  a  concept  phase,  requirements 
phase,  design  phase,  implementation  phase,  test  phase,  installation 
and  checkout  phase,  operation  and  maintenance  phase,  and, 
sometimes,  retirement  phase.  [IEEE-STD-610] 

Any  manager,  at  a  project  or  organizational  level,  who  has  direct 
responsibility  for  software  development  and/or  maintenance. 

The  collection  of  plans,  both  formal  and  informal,  used  to  express 
how  software  development  and/or  maintenance  activities  will  be 
performed.  Examples  of  plans  that  could  be  included:  software 
development  plan,  software  quality  assurance  plan,  software 
configuration  management  plan,  software  test  plan,  risk  management 
plan,  and  process  improvement  plan. 
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software  process 


software  process  assessment 


software  process  assets 
software  process  capability 
software  process  description 


software  process  element 


software  process  improvement 
plan 


software  process  improvement 
proposal 

software  process  maturity 


software  process  performance 

software  process-related 
documentatioii 


software  product 


soltware  project 


A  set  of  activities,  methods,  practices,  and  transformations  that 
people  use  to  develop  and  maintain  software  and  the  associated 
products  (e.g.,  project  plans,  design  documents,  code,  test  cases,  and 
user  manuals). 

An  appraisal  by  a  trained  team  of  software  professionals  to 
determine  the  state  of  an  organization's  current  software  process,  to 
determine  the  high-priority  software  process-related  issues  facing  an 
organization,  and  to  obtain  the  organizational  support  for  software 
process  improvement. 

(See  organization's  software  process  assets.) 

(See  process  capability.) 

The  operational  definition  of  a  major  software  process  component 
identified  in  the  project's  defined  software  process  or  the 
organization's  standard  software  process.  It  documents,  in  a 
complete,  precise,  verifiable  manner,  the  requirements,  design, 
behavior,  or  other  characteristics  of  a  software  process.  (See  also 
process  description.) 

A  constituent  element  of  a  software  process  description.  Each 
process  element  covers  a  well-defined,  bounded,  closely  related  set 
of  tasks  (e.g.,  software  estimating  element,  software  design  element, 
coding  element,  and  peer  review  element).  The  descriptions  of  the 
process  elements  may  be  templates  to  be  filled  in,  fragments  to  be 
completed,  abstractions  to  be  refined,  or  complete  descriptions  to  be 
modified  or  used  unmodified. 

A  plan,  derived  from  the  recommendations  of  a  software  process 
assessment,  that  identifies  the  specific  actions  that  will  be  taken  to 
improve  the  software  process  and  outlines  the  plans  for 
implementing  those  actions.  Sometimes  referred  to  as  an  action 
plan. 

A  documented  suggestion  for  change  to  a  process  or  process-related 
item  that  will  improve  software  process  capability  and  performance. 
(See  also  action  proposal.) 

The  extent  to  which  a  specific  process  is  explicitly  defined, 
managed,  measured,  controlled,  and  effective.  Maturity  implies  a 
potential  for  growth  in  capability  and  indicates  both  the  richness  of 
an  organization's  software  process  and  the  consistency  with  which  it 
is  applied  in  projects  throughout  the  organization. 

(See  process  performance.) 

Example  documents  and  document  fragments,  which  are  expected 
to  be  of  use  to  future  projects  when  they  are  tailoring  the 
org^ization's  standard  software  process.  The  examples  may  cover 
subjects  such  as  a  project's  defined  software  process,  standards, 
procedures,  software  development  plans,  measurement  plans,  and 
process  training  materials. 

The  complete  set,  or  any  of  the  individual  items  of  the  set,  of 
computer  programs,  procedures,  and  associated  documentation  and 
data  designated  for  delivery  to  a  customer  or  end  user.  [lEEE-STD- 
610]  (See  software  work  product  for  contrast.) 

An  undertaking  requiring  concerted  effort,  which  is  focused  on 
analyzing,  specifying,  designing,  developing,  testing,  and/or 
maintaining  the  software  components  and  associated  documentation 
of  a  system.  A  software  project  may  be  part  of  a  project  building  a 
hardware/software  system. 
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software  quality  assurance 

software  quality  goal 
software  quality  management 

software-related  group 

software  requirement 
software  work  product 

special  cause  (of  a  defect) 

staff 

stage 

standard 

standard  software  process 
statement  of  work 

subcontract  manager 
subcontractor 

system 


(1)  A  planned  and  systematic  pattern  of  all  actions  necessary  to 
provide  adequate  confidence  that  a  software  work  product  conforms 
to  established  technical  requirements.  (2)  A  set  of  activities 
designed  to  evaluate  the  process  by  which  software  work  products 
are  developed  and/or  maintained. 

Quantitative  quality  objectives  defined  for  a  software  work  product. 

The  process  of  defining  quality  goals  for  a  software  product, 
establishing  plans  to  achieve  these  goals,  and  monitoring  and 
adjusting  the  software  plans,  software  work  products,  activities,  and 
quality  goals  to  satisfy  the  needs  and  desires  of  the  customer  and 
end  users. 

A  collection  of  individuals  (both  managers  and  technical  staff) 
representing  a  software  engineering  discipline  that  supports,  but  is 
not  directly  responsible  for,  software  development  and/or 
maintenance.  Examples  of  software  engineering  disciplines  include 
software  quality  assurance  and  software  ccnfiguration  management. 

A  condition  or  capability  that  must  be  met  by  software  needed  by  a 
user  to  solve  a  problem  or  achieve  an  objective.  [IEEE-STD-610] 

Any  artifact  created  as  part  of  defining,  maintaining,  or  using  a 
software  process,  including  process  descriptions,  plans,  procedures, 
computer  programs,  and  associated  documentation,  which  may  or 
may  not  be  intended  for  delivery  to  a  customer  or  end  user.  (See 
software  product  for  contrast.) 

A  cause  of  a  defect  tliat  is  specific  to  some  transient  circumstance 
and  not  an  inherent  part  of  a  process.  Special  causes  provide 
random  variation  (noise)  in  process  perfonr-ance.  (See  common 
cause  for  contrast.) 

The  individuals,  including  task  leaders,  who  are  responsible  for 
accomplishing  an  assigned  function,  such  as  software  development 
or  software  configuration  management,  but  who  are  not  managers. 

A  partition  of  the  software  effort  that  is  of  a  manageable  size  and 
that  represents  a  meaningful  and  measurable  set  of  related  tasks 
which  are  performed  by  the  project.  A  stage  is  usually  considered  a 
subdivision  of  a  software  life  cycle  and  is  often  ended  with  a  formal 
review  prior  to  the  onset  of  the  following  stage. 

Mandatory  requirements  employed  and  enforced  to  prescribe  a 
disciplined  uniform  approach  to  software  development. 

(See  organization's  standard  software  process.) 

A  description  of  all  the  work  required  to  complete  a  project,  which  is 
provided  by  the  customer. 

A  manager  in  the  prime  contractor’s  organization  who  has  direct 
responsibility  for  administering  and  managing  one  or  more 
subcontracts. 

An  individual,  partnership,  corporation,  or  association  that  contracts 
with  an  organization  (i.e.,  the  prime  contractor)  to  design,  develop, 
and/or  manufacture  one  or  more  products. 

A  collection  of  components  organized  to  accomplish  a  specific 
function  or  set  of  functions.  [IEEE-STD-610] 
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system  engineering  group 

system  requirement 

system  requirements  allocated 
to  software 

T 

tailor 

target  computer 
task 

task  kick-off  meeting 
task  leader 

team 

testability 

technical  requirements 

technology 

tool* 


The  collection  of  individuals  (both  managers  and  technical  staff) 
who  have  responsibility  for  specifying  the  system  requirements; 
allocating  the  system  requirements  to  the  hardware,  software,  and 
other  components;  specifying  the  interfaces  between  the  hardware, 
software,  and  other  components;  and  monitoring  the  design  and 
development  of  these  components  to  ensure  conformance  with  their 
specifications. 

A  condition  or  capability  that  must  be  met  or  possessed  by  a  system 
or  system  component  to  satisfy  a  condition  or  capability  needed  by 
a  user  to  solve  a  problem.  (IEEE-STD-610] 

The  subset  of  the  system  requirements  that  are  to  be  implemented  in 
the  software  components  of  the  system.  The  allocated  requirements 
are  a  primary  input  to  the  software  development  plan.  Software 
requirements  analysis  elaborates  and  refines  the  allocated 
requirements  and  results  in  software  requirements  which  are 
documented. 


To  modify  a  process,  standard,  or  procedure  to  better  match  process 
or  product  requirements. 

The  computer  on  which  delivered  software  is  intended  to  operate. 
(See  host  computer  for  contrast.) 

(1)  A  sequence  of  instructions  treated  as  a  basic  unit  of  work. 
[IEEE-STD-610]  (2)  A  well-defined  unit  of  work  in  the  software 
process  that  provides  management  with  a  visible  checkpoint  into  the 
status  of  the  project.  Tasks  have  readiness  criteria  (preconditions) 
and  completion  criteria  (postconditions).  (See  activity  for  contrast.) 

A  meeting  held  at  the  beginning  of  a  task  of  a  project  for  the 
purpose  of  preparing  the  individuals  involved  to  perform  the 
activities  of  that  task  effectively. 

The  leader  of  a  technical  team  for  a  specific  task,  who  has  technical 
responsibility  and  provides  technical  direction  to  the  staff  working 
on  the  task. 

A  collection  of  people,  often  drawn  from  diverse  but  related  groups, 
assigned  to  perform  a  well-defined  function  for  an  organization  or  a 
project.  Team  members  may  be  part-time  participants  of  the  team 
and  have  other  primary  responsibilities. 

(1)  The  degree  to  which  a  system  or  component  facilitates  the 
establishment  of  test  criteria  and  the  performance  of  tests  to 
determine  whether  those  criteria  have  been  met.  (2)  The  degree  to 
which  a  requirement  is  stated  in  terms  that  permit  establishment  of 
test  criteria  and  performance  of  tests  to  determine  whether  those 
criteria  have  been  met.  [IEEE-STD-610] 

I'hose  requirements  that  describe  what  the  software  must  do  and  its 
operational  constraints.  Examples  of  technical  requirements  include 
functional,  performance,  interface,  and  quality  requirements. 

The  application  of  science  and/or  engineering  in  accomplishing 
some  particular  result. 

A  mechanism  that  provides  the  needed  support  for  organizational 
policies,  standards,  processes,  procedures,  and  training  in  order  to 
build  software  products. 
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traceability 


train 

training  group 


training  program 

training  waiver 

u 

unit 

user 

V 

validation 

verification 

verifying  implementation 

w 

wa»ver 

well-defined  process 

work  product* 


The  degree  to  which  a  relationship  can  be  established  between  two 
or  more  products  of  the  development  process,  especially  products 
having  a  predecessor-successor  or  master-subordinate  relationship  to 
one  another.  [IEEE-STD-610] 

To  make  proficient  with  specialized  instruction  and  practice.  (See 
also  orientation.) 

The  collection  of  individuals  (both  managers  and  staff)  who  are 
responsible  for  coordinating  and  arranging  the  training  activities  for 
an  organization.  This  group  typically  prepares  and  conducts  most 
of  the  training  courses  and  coordinates  use  of  other  training 
vehicles. 

The  set  of  related  elements  that  focus  on  addressing  an 
organization's  training  needs.  It  includes  an  organization's  training 
plan,  training  materials,  development  of  training,  conduct  of 
training,  training  facilities,  evaluation  of  training,  and  maintenance 
of  training  records. 

A  written  approval  exempting  an  individual  from  training  that  has 
been  designated  as  required  for  a  specific  role.  The  exemption  is 
granted  because  it  has  been  objectively  determined  that  the 
individual  already  possesses  the  needed  skills  to  perform  the  role. 


(1)  A  separately  testable  element  specified  in  the  design  of  a 
computer  software  component.  (2)  A  logically  separable  part  of  a 
computer  program.  (3)  A  software  component  that  is  not 
subdivided  into  other  components.  [IEEE-STD-610] 

(See  end  user.) 


The  process  of  evaluating  software  during  or  at  the  end  of  the 
development  process  to  determine  whether  it  satisfies  specified 
requirements.  [IEEE-STD-610] 

The  process  of  evaluating  software  to  determine  whether  the 
products  of  a  given  development  phase  satisfy  the  conditions 
imposed  at  the  start  of  that  phase.  [IEEE-S’IT>-610] 

(See  common  features.) 


(See  training  waiver). 

A  process  that  includes  readiness  criteria,  inputs,  standards  and 
procedures  for  performing  the  work,  verification  mechanisms  (such 
as  peer  reviews),  outputs,  and  completion  criteria.  (See  also  effective 
process.) 

Any  final  or  intermediate  product,  service,  or  result  of  a  process  or 
activity. 
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Appendix  C:  Role  Translation  Table 


Introduction  This  section  provides  definitions  of  the  major  roles  that  occur  in  the  CMM  and 
blank  role  translation  tables. 


Reference  Refer  to  Chapter  2,  “Features  of  the  Software  Process  Framework”  for  additional 
information  regarding  role  translation  tables. 


In  this  appendix  This  appendix  contains  the  following  sections: 


Definitions  of  Frequentiy  Used  Roies 


Definitions:  The  following  describes  roles  that  are  frequently  referenced  in  the  key  practices: 

Major  roles 

Manager  A  manager  fulfills  a  role  that  encompasses  providing  technical 

and  administrative  direction  and  control  to  individuals 
performing  tasks  or  activities  within  the  manager's  area  of 
responsibility.  The  traditional  functions  of  a  manager  include 
planning,  resourcing,  organizing,  directing,  and  controlling 
work  within  an  area  of  responsibility. 

Senior  manager  A  senior  manager  fulfills  a  management  role  at  a  high  enough 
level  in  an  organization  that  the  primary  focus  is  the  long-term 
vitality  of  the  organization,  rather  than  short-term  project  and 
contractual  concerns  and  pressures.  In  general,  a  senior 
manager  for  engineering  would  have  responsibility  for 
multiple  projects.  A  senior  manager  also  provides  and  protects 
resources  for  long-term  improvement  of  the  software  process 
(e.g.,  a  software  engineering  process  group). 

Senior  management,  as  used  in  the  CMM,  can  denote  any 
manager  who  satisfies  the  above  description,  up  to  and 
including  the  head  of  the  whole  organization.  As  used  in  the 
key  practices,  the  term  senior  management  should  be 
interpreted  in  the  context  of  the  key  process  area  and  the 
projects  and  organization  under  consideration.  The  intent  is 
to  include  specifically  those  senior  managers  who  are  needed 
to  fulfill  the  leadership  and  oversight  roles  essential  to 
achieving  the  goals  of  the  key  process  area. 

Project  manager  A  project  manager  fulfills  the  role  with  total  business 

responsibility  for  an  entire  project;  the  project  manager  is  the 
individual  who  directs,  controls,  administers,  and  regulates  a 
project  building  a  software  or  hardware/software  system.  The 
project  manager  is  the  individual  ultimately  responsible  to  the 
customer. 

in  a  project-oriented  organizational  structure,  most  of  the 
people  working  on  a  project  would  report  to  the  project 
manager,  although  some  disciplines  might  have  a  matrixed 
reporting  relationship.  In  a  matrixed  organizational  structure, 
it  may  be  only  the  business  staff  who  reports  to  the  project 
manager.  The  engineering  groups  would  then  have  a 
matrixed  reporting  relationship. 

Project  software  A  project  software  manager  fulfills  the  role  with  total 

manager  responsibility  for  all  the  software  activities  for  a  project.  The 

project  software  manager  is  the  individual  the  project  manager 
deals  with  in  terms  of  software  commitments  and  who  controls 
all  the  software  resources  for  a  project. 

The  software  engineering  groups  on  a  project  would  report  to 
the  project  software  manager,  although  some  activities  such  as 
tools  development  might  have  a  matrixed  reporting 
relationship. 

Definition  continued  on  next  page 


Continued  on  next  page 
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Definitions  of  Frequently  Used  Roles,  Continued 


Definitions: 
Major  roles, 
continued 


The  following  descrioes  roles  that  are  frequently  referenced  in  the  key  practices, 
continued  from  the  previous  page: 


In  a  large  project,  the  project  software  manager  is  likely  to  be 
a  second-,  third-,  or  fourth-line  manager.  In  a  small  project  or 
department  with  a  single  project,  the  project  software  manager 
might  be  the  first-line  software  manager  or  might  be  at  a 
higher  level. 

A  first-line  software  manager  fulfills  the  role  with  direct 
management  responsibility  (including  providing  technical 
direction  and  administering  the  personnel  and  salary 
functions)  for  the  staffing  and  activities  of  a  single 
organizational  unit  (e.g.,  a  department  or  project  team)  of 
software  engineers  and  other  related  staff. 

A  software  task  leader  fulfills  the  role  of  leader  of  a  technical 
team  for  a  specific  task.  A  software  task  leader  has  technical 
responsibility  and  provides  technical  direction  to  the  staff 
working  on  the  task. 

The  software  task  leader  usually  reports  to  the  same  first-line 
software  manager  as  the  other  people  who  are  woricing  on  the 
task. 

Staff,  software  Several  terms  are  used  in  the  CMM  to  denote  the  individuals 
engineering  staff,  who  perform  the  various  technical  roles  described  in  various 
individuals  key  practices  of  the  CMM.  The  staff  are  the  individuals, 

including  task  leaders,  who  are  responsible  for  accomplishing 
an  assigned  function,  such  as  software  development  or 
software  configuration  management,  but  who  are  not 
managers. 

The  software  engineering  staff  are  the  software  technical 
people  (e.g.,  analysts,  programmers,  and  engineers),  including 
software  task  leaders,  who  perform  the  software  development 
and  maintenance  activities  for  the  project,  but  who  are  not 
managers. 

The  term  "individuals"  as  used  in  the  key  practices  is  qualified 
and  funded  by  the  context  in  which  the  term  appears  (e.g., 
"the  individual  involved  in  managing  the  software 
subcontract"). 


Project  software 

manager, 

continued 


First-line  software 
manager 


Software  task 
leader 
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Definitions  of  Frequently  Used  Roles,  Continued 


Definition: 

Concepts 


Definitions: 

Groups 


The  fundamental  concepts  of  organization,  project,  and  group  must  be  understood 
to  interpret  the  key  practices  of  the  Capability  Maturity  Model  properly.  The 
following  paragraphs  define  the  use  of  these  concepts  in  the  CMM: 

Organization  An  organization  is  a  unit  within  a  company  or  other  entity 
(e.g.,  government  agency  or  branch  of  service)  within  which 
many  projects  am  managed  as  a  whole.  All  projects  within  an 
organization  share  a  common  top-level  manager  and  common 
policies. 

Project  A  project  is  an  undertaking  requiring  concerted  effort,  which 

is  focused  on  developing  and/or  maintaining  a  specific 
product.  The  product  may  include  hardware,  software,  and 
other  components.  Typically  a  project  has  its  own  funding, 
cost  accounting,  and  delivery  schedule. 

Group  A  group  is  the  collection  of  departments,  managers,  and 

individuals  who  have  responsibility  for  a  set  of  tasks  or 
activities.  A  group  could  vary  from  a  single  individual 
assigned  part  time,  to  several  part-time  individuals  assigned 
from  different  departments,  to  several  individuals  dedicated 
full  time. 


Groups  commonly  referred  to  in  the  CMM  are  described  below: 


Software 

engineering 

group 


Software-related 

groups 


Software 
engineering 
process  group 


The  software  engineering  group  is  the  collection  of  individuals 
(both  managers  and  technical  staff)  who  have  responsibility 
for  software  development  and  maintenance  activities  (i.e., 
requirements  analysis,  design,  code,  and  test)  for  a  project. 

Groups  performing  software-related  work,  such  as  the  software 
quality  assurance  group,  the  software  configuration 
management  group,  and  the  software  engineering  process 
group,  are  not  included  in  the  software  engineering  group. 
These  groups  are  considered  to  be  one  of  the  "other  software- 
related  groups." 

A  software-related  group  is  the  collection  of  individuals  (both 
managers  and  technical  staff)  representing  a  software 
engineering  discipline  that  supports,  but  is  not  directly 
responsible  for,  software  development  and/or  maintenance. 

Examples  of  software  engineering  disciplines  include  software 
quality  assurance  and  software  configuration  management. 

The  software  engineering  process  group  is  the  group  of 
specialists  who  facilitate  the  definition,  maintenance,  and 
improvement  of  the  software  process  used  by  the  organization. 
In  the  key  practices,  this  group  is  generically  referred  to  as 
"the  group  responsible  for  the  organization's  software  process 
activities." 


Continued  on  next  page 
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Definitions  of  Frequently  Used  Roles,  Continued 


Definitions: 

Groups, 

continued 


Groups  commonly  referred  to  in  the  CMM  are  described  below,  continued  from 
the  previous  page: 


System 

engineering 

group 


System  test  group 


Software  quality 
assurance  group 


Software 

configuration 

management 

group 

Training  group 


The  system  engineering  group  is  the  collection  of  individuals 
(both  managers  and  technical  staff)  who  have  responsibility 
for  specifying  the  system  requirements;  allocating  the  system 
requirements  to  the  hardware,  software,  and  other  components; 
specifying  the  interfaces  between  the  hardware,  software,  and 
other  components;  and  monitoring  the  design  and 
development  of  these  components  to  ensure  conformance  with 
their  s^cifications. 

The  system  test  group  is  the  collection  of  individuals  (both 
managers  and  technical  staff)  who  have  responsibility  for 
planning  and  performing  the  independent  system  testing  of 
the  software  to  determine  whether  the  software  product 
satisfies  its  requirements. 

The  software  quality  assurance  group  is  the  collection  of 
individuals  (both  managers  and  technical  stafO  who  plan  and 
implement  the  project's  quality  assurance  activities  to  ensure 
the  software  process  steps  and  standards  are  followed. 

The  software  configuration  management  group  is  the 
collection  of  individuals  (both  managers  and  technical  staff) 
who  have  responsibility  for  planning,  coordinating,  and 
implementing  the  formal  configuration  management  activities 
for  the  software  project. 

The  training  group  is  the  collection  of  individuals  (both 
managers  and  staff)  who  are  responsible  for  coordinating  and 
arranging  the  training  activities  for  an  organization.  Hiis 
group  typically  prepares  and  conducts  most  of  the  training 
courses  and  coordinates  use  of  other  training  vehicles. 
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Role/KPA  Matrix 


Purpose  The  purpose  of  the  role/KPA  matrix  is  to  allow  users  to  find  the  roles  referenced  in 

a  KPA  rapidly.  A  secondary  purpose  is  to  allow  users  to  quickly  identify  the  KPAs 
in  which  a  role  is  referenced. 


Expected  use  There  will  be  cases  in  which  an  organization  is  focused  on  only  a  portion  of  the 
CMM,  and  thus  interested  in  a  few  KPAs.  In  this  c^e,  the  role/KPA  matrix  will 
allow  the  user  to  make  only  the  neccessary  translations. 


Role/KPA  The  following  matrix  shows  each  CMM  role  and  the  KPA  in  which  it  appears, 
matiix  _ _ 
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Role/KPA  Matrix,  Continued 


Role/KPA  The  following  matrix  shows  each  CMM  role  and  the  KPA  in  which  it  appears, 

matrix,  continued  from  the  previous  page. 

continued 
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Role/KPA  Matrix,  Continued 


Roie/KPA  The  following  matrix  shows  each  CMM  role  and  the  KPA  in  which  it  appears, 

matrix,  continue  .  from  the  previous  page. 
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Role/KPA  Matrix,  Continued 


Role/KPA  The  following  matrix  shows  each  CMM  role  and  the  KPA  in  which  it  appears, 

matrix,  continued  from  the  previous  page. 
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Role/KPA  Matrix,  Continued 


Role/KPA  The  following  matrix  shows  each  CMM  role  and  the  KPA  in  which  it  appears, 

matrix,  continued  from  the  previous  page. 
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Role/KPA  Matrix.  Continued 


Role/KPA  The  following  matrix  shows  each  CMM  role  and  the  KPA  in  which  it  appears, 
matrix,  continued  from  the  previous  page. 

continued  _ 
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Role/KPA  Matrix,  Continued 


Role/KPA 

matrix, 

continued 


The  following  matrix  shows  each  CMM  role  and  the  KPA  in  which  it  appears, 
continued  from  the  previous  page. 


Levels 


Level  4  Level  5 


RS  S  S  S]S  OOTI  S  !  P  QS  DTP 
MPPS  QCPPPS  PCRPQPCC 


P  T  M  A  M  F  D 
O 


M  M 


Technology  suppliers 
Test  group 


Role  Translation  Table 


Role  translation  Fill  in  the  equivalent  role  for  your  organization  in  the  table  below. 

table 


CMM  Roles/Groups 

Your  Organization’s  Roles/Groups 

Administrative  personnel 

Affected  groups 

Affected  individuals 

Affected  managers 

Customer 

Customer  SQA  personnel 

Documentation  specialist 

End  user 

Engineering  group 

Experienced  individuals  who  have 
expertise  in  defining  and  analyzing 
software  processes 

Experts  independent  of  the  SQA 
group 

First-line  software  managers 

Group  responsible  for  analyzing  and 
allocating  system  requirements 

Group  responsible  for  coordinating 
the  organization's  software  process 
activities  (e.g.,  SEPG) 

Group  responsible  for  coordinating 
the  quantitative  process  management 
activities  for  the  organization 

Group  responsible  for  providing  the 
critical  dependency  item 

Group  responsible  for  system  and 
acceptance  testing 

Group  responsible  for  the  organiza¬ 
tion’s  technology  change  management 
activities 

Group  responsible  for  the  organiza¬ 
tion’s  software  process  activities 

Group  responsible  for  the  system 
requirements 

Group  that  defines  and  maintains  the 
affected  process  descriptions 
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Role  Translation  Table,  Continued 


Role  translation  Fill  in  the  equivalent  role  for  your  organization  in  the  table  below,  continued  from 
table,  continued  the  previous  page. 


CMM  Role 


Groups  involved  in  implementing  the 
software  processes 


Group  that  is  independent  of  the 
software  engineering  group 


Individuals 


Individuals  and  groups  external  to  the 
organization 


Individuals  implementing  and 
supporting  software  quality 
management 


Individuals  implementing  or 
supporting  quantitative  process 
management 


Individuals  (involved  in  coding) 


Individuals  (involved  in  developing  the 
software  requirements) 


Individuals  (involved  in  software 
design) 


Individuals  (responsible  for  the 
software  design) 


Individuals  (responsible  for  the 
software  requirements) 


Individuals  responsible  for  developing 
the  project's  defined  software  process 


Individuals  responsible  for 
implementing  the  software  processes 


Individuals  who  develop  and  maintain 
the  organization's  standard  software 
process  and  related  process  assets 


Management 


Manager 


Managers  of  the  affected  groups 


Managers  of  the  software  engineering 
groups 


Your  Organization’s  Role(s) 
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Role  Translation  Table,  Continued 


Role  translation  Fill  in  the  equivalent  role  for  your  organization  in  the  table  below,  continued  from 
table,  continued  the  previous  page. 


CMM  Role 

Your  Organization’s  Role(s) 

Managers  of  software-related  groups 

Members  of  the  organization 

Organization’s  managers 

Peer  review  checklist  developers’  peers 

Pee''  jview  leader 

Peer  review  checklist  potential  users 

Person  responsible  for  each 
configuration  item/unit 

Person  trained  in  conducting  casusal 
analysis  meetings 

Prime  contractor 

Prime  contractor's  management 

Prime  contractor's  SCM  group 

Prime  contractor's  SQA  group 

Producer 

Project 

Project  manager 

Project  software  manger 

Receiving  group  of  a  critical 
dependency  item 

Representatives  of  the  project’s 
software  engineering  group 

Representatives  of  the  other 
engineering  groups 

Representatives  of  the  project 
engineering  groups 

Representatives  of  the  receiving  group 
of  a  critical  dependency  item 

Reviewer 

Senior  management 

Senior  manager 

SCCB 

SCM  group 

Software  engineering  group 
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Role  Translation  Table,  Continued 


Role  translation  Fill  in  the  equivalent  role  for  your  organization  in  the  table  below,  continued  from 
table,  continued  the  previous  page. 


CMM  Role 


Software  engineering  managers 


Software  engineering  technical  staff 


Software  engineer 


Software  maintainer 


Software  manager 


Software-related  groups 


Software  subcontractor 


Software  subcontractor  groups 


Software  subcontractor’s  management 


Software  subcontractor's  software 
engineering  group 


Software  task  leader 


Specialty  engineers  in  areas  such  as 
safety  and  reliabilty 


SQA  group 


Staff 


Subcontract  bidder 
Subcontract  manager 
Subcontractor 

Submitters  of  the  action  proposals 

Submitters  of  the  software  process 
improvement  proposals 


System  engineering  group 


Task  leaders 


Task  leaders  of  other  software-related 
groups 


Task  leaders  of  the  software 
engineering  groups 


Team  of  peers  and  experts 


Team  performing  the  software  task 


Team  responsible  for  implementation 
of  software  process  improvement 
actions 


Your  Organization’s  Role(s) 
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Role  Translation  Table,  Continued 


Role  translation  Fill  in  the  equivalent  role  for  your  organization  in  the  table  below,  continued  from 
table,  continued  the  previous  page.  Blank  entries  are  provide  for  your  use. 


CM  M  Role 

Your  Organization’s  Roie(s) 

Teams  assigned  to  coordinate  defect 
prevention  activities 

Teams  at  another  level  in  the 
organization 

Technical  staff 

Technical  staff  of  the  software-related 
groups 

Technical  staff  of  the  software 
engineering  group 

Technology  suppliers 

Test  group 

Training  group 
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Appendix  D:  General  Term  Translation  Table 


Reference 


General  term 

translation 

table 


Refer  to  Chapter  2,  “Features  of  the  Software  Process  Framework”  for  additional 
informatioi\  regarding  general  term  translation  tables. 


Fill  in  the  equivalent  term  for  your  organization  in  the  table  below.  Blank  rows  are 
provided  for  additional  terms. 


CMM  General  Terms 

Your  Organization’s  Teim 

Organization 

Product 

Project 

Software  product 

Software  project 

System 
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